File and Line Size Limitations

MediaMath’s SFTP server will not accept an upload larger than 4 GB.  Files exceeding 4 GB will be rejected.  If you have a file that exceeds this size, split the file and deliver it as separate files.

Each line in the file must be fewer than 8,000 characters. If a line in your file exceeds 8,000 characters, split the line into separate lines and restate the MMUID in the new line.

To maintain service stability, MediaMath limits data delivery to a maximum of 5 GB per day and 20 files per hour. These quotas are reset at midnight UTC and every hour on the hour, respectively. These maxima can be reevaluated as needed; please contact your MediaMath relationship manager as needed.

 

Managing Integrations Based on Data Type

Data providers who deliver more than 10 GB of data per day must leverage distinct integrations (with their own SFTP endpoints) based on various data types.  This allows MediaMath to expedite loading the data and allows you to better comply with best practices on data delivery & refreshes.  Examples of distinct integrations typically include:

  • 1PD: First Party Data (defined as data originating from the end client/marketer) must be split into its own distinct integration. Depending upon the size of this integration, we can split this into “1pd-cookie” and “1pd-mobile”.
  • Standard 3PD: Public (global) taxonomies that the provider makes available in T1 at the public/global level must be split into its own integration. These taxonomies are generally somewhat standard and do not vary by client or campaign.  They can include the direct provider’s owned data as well as data syndicated or resold by the provider.  Depending upon the size of this integration, we can split this into “3pd-standard-cookie” and “3pd-standard-mobile”.
  • Custom 3PD: Private (permissioned) taxonomies that the provider makes available to specified organizations, agencies and/or advertisers in T1 must be split into its own integration. These taxonomies are generally custom and made available to specific clients (and often vary on a campaign-by-campaign basis).  They can include the direct provider’s owned data as well as data syndicated or resold by the provider. Depending upon the size of this integration, we can split this into “3pd-custom-cookie” and “3pd-custom-mobile”.

 

Delivering Data: Cadence and Content

 Delivering Efficient Incremental Updates Daily

You should deliver “incremental” updates daily (as opposed to comprehensive user refreshes, which should only be delivered once every 30-45 days; see next section).  This means that each day, you should only upload new segment membership for existing users or full segment membership for new users.  For example:

 

  • Day One: On the first day, the partner uploads two new users (AA and BB) with their complete segment membership at that time
  • Day Two:
    • Existing user AA is added to segment 1C. You should only send the new segment for this user (1C) as opposed to resending existing segments (1A/1B)
    • New user CC is added to three segments (1A, 1B, 1C). You can send all three segments for this new user.
    • There is no need to resend any segment membership for existing user BB, as this user was not added to any new segments
  • Day Three:
    • Existing user BB was added to segment 1D. You should only send the new segment for this user (1D) as opposed to resending existing segment (1A/1B/1C)
    • There is no need to resend any segment membership for other existing users (AA/CC), as these users were not added to any new segments

 

Sending incremental updates will ensure data is loaded efficiently, consistently, and reliably into T1.

 Do not distribute the full segment membership of an existing user when adding the user to a new segment.  Only distribute the new segment for the user. For example, the following is an inefficient form of data delivery:

 

  • There is no need to send segments 1A and 1B for user AA on day 2 (as this data / segment membership already exists within our user database)
  • There is no need to send segments 1A, 1B, and 1C for user BB on day 3 (as this data / segment membership already exists within our user database)
  • If you deliver data inefficiently (as described here), you will be subject to data delays, possible suspensions or reductions in quota limits.

 

Do not distribute full comprehensive updates each day, as shown in the example below:

 

  • The above represents the exact opposite of “incremental” data uploads.
  • While day 1 in the above is OK, the following is inefficient as the users which were re-syndicated to our platform were already in the user database:
    • There was no need to send segments 1A and 1B for user AA on day 2.
    • There was no need to send any segments for user BB on day 2.
    • There was no need to send any segments for user AA on day 3.
    • There was no need to send segments 1A, 1B, and 1C for user BB on day 3.
    • There was no need to send any segments for user CC on day 3.
  • If you deliver data inefficiently (as described here), you will be subject to data delays, possible suspensions or reductions in quota limits.

 

Delivering Comprehensive User Refreshes Every 30-45 Days

Segment membership is stored by MediaMath for a guaranteed minimum of 45 days.  As such, to ensure users remain in their appropriate segments, if you are sending data incrementally as described above, you should plan to send refreshes of their data every 30-45 days.  When doing so, please ensure the following:

  • The refresh should be done every 30-45 days.
  • The refresh should be spread over a 2-4 day period (to remain within your allotted daily quota).
  • The refresh should be done over a weekend (ideally starting Friday night and ending mid-day Monday).

 

Continuing the above example (assuming no users were added to any new segments from day 4 through day 30), the refresh would be delivered over 3 days and would include full segment membership, like this:

 

Delivering Taxonomies

MediaMath has created a Taxonomy API in order to make segments available for activation programmatically. The Taxonomy API can be used to expose in T1:

  • Standard public (global) taxonomies
  • Custom private (permissioned) taxonomies, which expose 1st and/or 3rd party segments to specified organizations, agencies and/or advertisers in T1.

 

Any entity sending data to MediaMath has the ability to integrate with this API in order to create, manage and update taxonomies (private and public) on a self-serve basis. This includes updating segment names, ID’s, uniques volumes, and CPMs, as well as segment removal.

Documentation for the Permissioned Taxonomy API can be found here. Using the API gives vendors complete transparency and control over onboarding and activating data for targeting within T1 and reduces the turnaround time from days to hours. Vendors can now add/remove segments from a taxonomy and assign/revoke permissions to certain organizations, agencies and advertisers within T1 without assistance from a MediaMath representative. If you have additional questions about the API documentation, please reach out to your MediaMath Account representative.

 

Last Revised:  March 20, 2019