Third Party Data Provider Integration Guide

1. Introduction

The Salesforce DMP supports ingestion and use of data provided by parties other than the direct Salesforce DMP client. In this case, the data is generally treated as "third-party data". Third-party data is stored in a special account within the DMP and can be made available to any Salesforce DMP client, with agreement of the third-party data provider.    

By default, Salesforce DMP will allow the data to be generally used by all Salesforce DMP clients.  However, Salesforce DMP can support certain datasets to just one or several named clients and will provision specific destination folders and taxonomies to handle those cases.  If there are any restrictions on what clients can use the data, or if special paperwork is required, please inform Salesforce DMP.

2. Integration Models

This section describes the various integration models open to third-party data providers.

2.1 Server-to-Server Integration [Preferred Method]

The Server-to-Server (S2S) integration method involves three steps:

  1. Cookie Matching: Salesforce DMP and the third-party data provider synch their respective user IDs via "Cookie-Matching". This is described in Section 2.1.1
  2. Data Files: The data provider sends daily data files to Salesforce DMP's Amazon S3 account. Full and daily refreshes are preferred. This is described in Section 2.1.2
  3. Segment Taxonomy: The third-party data provider sends Salesforce DMP a meta-file containing: segment ids, names, categories and prices periodically, as it changes. This is described in detail in Section 3.

2.1.1 Cookie Matching

Cookie matching is the process of syncing user IDs between Salesforce DMP and the data provider. The user match can be initiated either by the data provider or by Salesforce DMP. In either case, Salesforce DMP will keep the user match table.

If Partner wants Salesforce DMP to initiate this call, the following process should be followed.

  1. Partner provides Salesforce DMP with a cookie-match URL
  2. Salesforce DMP provides Partner a user match pixel which Partner should redirect to from the above pixel. This should be a HTTP 302 redirect to the Salesforce DMP pixel with the partner user ID.
  3. Salesforce DMP fires Partner's cookie-match URL on client's web sites. All cookie-match pixels are frequency-capped to 3 per day per user.

Please contact the Salesforce DMP Solutions team to get the Salesforce DMP pixel where Partner should redirect to after including their user ID.

If Partner wants to initiate this call, the following process should be followed:

  1. Salesforce DMP provides partner a user match pixel which partner should fire from all across their network.
  2. The above pixel fire should include the partner user ID.

Note: For Mobile data, Salesforce DMP uses IDFAs/Advertising Id as the unique identifier. There is no cookie syncing required if the partner data is available by IDFA/Advertising Id.

2.1.2 Data Files

The data files present the format in which partners should provide data to Salesforce DMP keyed off the partner's user ID.

Salesforce DMP will provide an Amazon S3 location and the format to ingest these data files from the partner.

The format for data files is:

user_id^S1, S2, S3
user_id = The data provider user ID
table S#_ = IDs of data provider segments that match names in taxonomy file

For Mobile data, the partner user_id can be IDFA/Advertising Id.

Please refer to Section 3 for details on the taxonomy file.

2.2. Pixel-based Integration

For pixel based integration, the following steps should be followed:

  1. Partner provides Salesforce DMP with a pixel to fire that will transmit segments to Salesforce DMP.
  2. Salesforce DMP will fire Partner pixel via Salesforce DMP's tag management solution.
  3. The Partner pixel must redirect to a Salesforce DMP pixel after appending the segments that a user belongs to.
  4. Salesforce DMP will be able to associate these segments from the above redirect.

Please contact your Salesforce DMP Representative on theSalesforce DMP Solutions team for the Salesforce DMP pixel to redirect.

3. Segment Taxonomy File

Regardless of the integration approach, the data provider will provide Salesforce DMP with a meta-file in .csv format.

Salesforce DMP will provide an Amazon S3 location and the format to ingest these taxonomy files from the partner.

At a minimum, the file format must include: segment_id, segment_name, price and segment description

Optionally, you can send 2 parent levels for a segment. In the example below, Category 1 and Category 2 are optional but supported in the Salesforce DMP Platform. If you have allow for segment targeting at the node level, you will have a segment_name, segment_id, and price, so make sure that the information is in the correct columns. For example, the data provider may wish to only have the end nodes selectable (eg: Male, Female), in which case there are only two entries for that Category. However, if the data provider would like to enable targeting at the category level as well as the child level, then the category should be listed as a segment and include a price.  In the example below, the Auto category is targetable and therefore has a segment name, id, and price.  However only specific types of credit cards are targetable, and not the Credit Card category.

Category 1 Category 2 segment_name segment_id price ($)
Top Level Second Level Segment to select ID that matches data file CPM price
example: Demographics  example: Gender example: Female  example: 11111 example: 1.00
example: Demographics example:
Gender
example:
Male
example:
22222
example: 1.00
example: Intent   example: Auto  example: 333333
example: 3.00
example: Intent example: Auto example: Toyota example: 44444 example: 4.00
example: Intent example: Auto example: Honda example: 55555 example: 4.00
example: Finance example: Credit Card example: Amex example: 66666 example: 2.50
example: Finance example: Credit Card example: Visa example: 77777 example: 2.50

Note: if you are adding the categories, the last three columns must always be: segment_name, segment_id, price

Some other considerations:

  • All records must have the same number of fields when split by a comma (",")
  • All segment IDs must be unique
  • IDs can be alpha, numeric, or alpha-numeric, as long as they match the IDs in the data file.
  • Do not include Data Provider name as a Category, it will already be listed as the top level of the taxonomy tree.
  • The segment names and groups will be displayed in Salesforce DMP's UI to operators. We highly recommend using clear, logical names for audience building.
  • All CPMs need to be in USD ($)
  • Please avoid all capital letters.  ‘Sentence Case’ or ‘Capitalize Every Word’ both work.
  • There is a 256 character limit per each: Category, Sub-Category, or Segment Name field”  The system will reject anything 256 characters or above.
  • Escape any fields with "quotes" when commas are used.  For ex: House Hold Income,"$50,000 - $100,000",1234,1 

4. Taxonomy Updates

Salesforce DMP supports taxonomy updates for new segments, removed segments, or for price changes.

Taxonomy updates should be a full refresh with every segment indicated in the taxonomy. Also, updates are not supported more than once a quarter.

5. Usage Report

The Salesforce DMP monitors client data usage in ad servers and other execution platforms by ingesting log files, API, or Impression Tracking reports that contain the Krux User ID. By matching these IDs back to segment rules, the platform is able to report on the actual usage of data by each client of each data provider's segments.

Salesforce DMP generates third-party data provider usage reports monthly. We do our best effort to provide reporting by the 15th working day following the end of the previous month. The format of the reporting is shown below.

Salesforce DMP Customer, Segment Name, Segment ID, CPM, Impressions, Cost

6. Allocation Rules

The Salesforce DMP Platform is very flexible in its ability to allow a client to define segment rules. Specifically, the Platform allows clients to build a segment based on any combination of one or more data providers' segments with one or more first-party data attributes. Because of this capability, the evaluation of the appropriate credit to be assigned to any one data provider can be quite complex.

Salesforce DMP has implemented a data provider allocation methodology known as "Fair Share" to determine the specific impression credit that will be assigned. This methodology evaluates the rules for an individual Salesforce DMP segment in light of the actual data provider segment membership and first-party data attributes of each user who was served an ad based on their membership in that Salesforce DMP segment.

The specific rules applied are described below.

Multiple Data Providers connected with an "AND"

Example: Salesforce DMP Segment Rule: DP1 = Value1 AND DP2 = Value2

Note: Both Data Providers are required to serve the impression

Credit Allocation:
Both DP1 and DP2 receive 1 full credit

Multiple Data Providers connecters with an "OR"

Example: Salesforce DMP Segment Rule: DP1 = Value1 OR DP2 = Value2

Credit Allocation:

  • Only DP1/Value1 exists — DP1 receives 1 credit, DP2 receives 0 credit
  • Only DP2/Value2 exists — DP2 receives 1 credit, DP1 receives 0 credit
  • Both DP1/Value1 and DP2/Value2 exist — Both DP1 and DP2 get 1/2 credit

Multiple Data Providers connected with "AND" and Publisher Data connected with "AND"

Example: Salesforce DMP Segment Rule: DP1 = Value1 AND DP2 = Value2 AND PubAttrib1 = Value3

Note: Both Data Providers and Pub attribute are required to serve the impression

Credit Allocation:
Both DP1 and DP2 receive 1 full credit Scenario

Multiple Data Providers connected with "OR" and Publisher Data connected with "OR"

Example: Salesforce DMP Segment Rule: DP1 = Value1 OR DP2 = Value2 OR PubAttrib1 = Value3

Credit Allocation:

  • Only DP1/Value1 exists — DP1 receives 1 credit, DP2 receives 0 credit
  • Only DP2/Value2 exists — DP2 receives 1 credit, DP1 receives 0 credit
  • Only PubAttrib1/Value3 exists — No credit is given to either Data Provider
  • Both DP1/Value1 and DP2/Value2 exist, but, PubAttrib1/Value3 does not exist — Both DP1 and DP2 get 1/2 credit
  • All of DP1/Value1, DP2/Value2, and PubAttrib1/Value3 exist — Both DP1 and DP3 get 1/3 credit

Need Help?

If you need help with Third-party Data Provider Integration, don't hesitate to contact the Salesforce DMP Support team at kruxhelp@krux.com.

Have more questions? Submit a request

0 Comments

Article is closed for comments.