Introduction
This document provides a step-by-step approach to pushing client data from the Salesforce Data Management Platform to Activation/Execution Partners such as Demand Side Platforms (DSP), Supply Side Platforms (SSP), Ad Networks, and Exchanges. For simplicity the rest of the document refers to all Activation/Execution Partners as Data Receivers.
Salesforce Audience Studio supports data transfer via the Server-to-Server method. This method involves user matching and subsequent pushing of data in batch. In addition to supporting device types that require user matching, hashed email addresses, OTT devices, and other customer first party IDs are supported. The server-to-server method is described in greater detail below.
When a mutual customer establishes a connection between Audience Studio and an Activation Partner, that customer must explicitly choose to send readable segment names instead of segment IDs.
Server-to-Server Integration
Server-to-Server integration involves the following steps in addition to an initial integration configuration where you will have the opportunity to define the types of devices supported, such as cookies, mobile ids, hashed email address OTT devices, and the specific supported hash methods and OTT device types.
Step 1: User Matching
This step executes a User Match with the Data Receiver via a user-match URL. Audience Studio stores the user match table and all data is keyed off the Data Receiver’s User ID.
Audience Studio will provide a user match pixel which is of the following format:
https://beacon.krxd.net/usermatch.gif?partner=YYY&partner_uid=ZZZWhere:
YYY=partner name assigned by Audience Studio to the partner
ZZZ=partner userid for the user
The above user match url works for both secure and non secure ports. However, we prefer that the data receiver fires the secure url.
The user match can be initiated in two different ways.
1. Partner calls the user match pixel:
Audience Studio requires that data receiver fires our user match pixels all across their network. The Data Receiver should fire the Audience Studio user match pixel across their network for maximum scale of client campaigns. Our user match pixels support both secure and non-secure ports and should be called from both places.
An example:
https://beacon.krxd.net/usermatch.gif?partner=YYY&partner_uid=ZZZWhere:
YYY = the partner name assigned by Audience Studio
ZZZ = the partner's userid
The above pixel returns a 204 No Content HTTP Response.
2. Audience Studio calls the partner redirect pixel:
Audience Studio calls partner's user-match URL on the relevant client pages and on ad campaigns. All pixels are frequency-capped appropriately per day per user per domain. This url has to be a redirect url which in turn calls Audience Studio usermatch pixel after it appends the partner user id to the Audience Studio usermatch pixel.
An Example:
https://kruxpartner.net/cookiematch?partner_id=XXX&redir=https://beacon.krxd.net/usermatch.gif?partner=YYY&partner_uid=ZZZWhere:
XXX = the id that the partner assigns to Audience Studio
YYY = the partner id assigned by Audience Studio
ZZZ = the partner's userid
The above pixel returns a 204 No Content HTTP Response.
Note that Audience Studio can call another pixel's redirect, but Audience Studio does not support redirect alone.
Step 2: Data Location
Audience Studio will grant access to the Audience Studio Amazon credential generation tool, giving the Data Receiver access to user audience segment map via an Amazon S3 folder in Audience Studio's Amazon account.
The data is specified in the following folder:
s3://<partner_home_directory>/<date>/<client_name>/<account_name>/<files>Where:
<partner_home_directory>: directory provided to the partner by Audience Studio <date>: date which is of the format YYYY-MM-DD (2019-09-01). The date corresponds to the date that the data was uploaded
<client_name>: Audience Studio client for which data is provided
<account_name>: Audience Studio Client account name for which data is provided
<files>: One or more files with data. The content of these files are described below in Step 4
Step 3: File Details
Audience Studio will deliver one or more .gz compressed data files each day to partner specific S3 bucket containing the daily segment map information. The delivery location will remain constant, though the number and naming of files may vary due to back end processing.
Audience Studio will send file uploads each day. Once the Data Receiver specifies the type of match keys accepted (cookie, mobile ID), Audience Studio will configure the jobs to push the accepted types. Files will be separated based on Match Key, and the file name will be prepended accordingly.
A <YYYY-MM-DD>.COMPLETE file will be available when all files per day have been generated. This indicates files are ready for import into your platform. If the Data Receiver does not see any data files on Amazon S3, then either there were no segments to be pushed that day, or the push timed out, in which case Audience Studio will be notified by our monitoring systems and will work to fix the issue. The Data Receiver is responsible for picking up the files from S3 for ingestion. Audience Studio ensures User Audience files stay in the folder for at least 7 days.
Following is an example of a daily push of cookies, mobile IDs, hashed email addresses, and OTT devices into a Data Receiver’s folder. HEM hash types and OTT device types are delivered via separate files based on the methods and types configured for your integration. You must request to configure supported device types before that device type data will be delivered to your S3 location.
2016-09-09.COMPLETE
AAID_<account_name>_segments_map_2016-09-01.csv-r-00000.gz
AAID_<account_name>_segments_map_2016-09-01.csv-r-00001.gz
AAID_<account_name>_segments_map_2016-09-01.csv-r-00002.gz
COOKIE_<account_name>_segments_map_2016-09-01.csv-r-00000.gz
COOKIE_<account_name>_segments_map_2016-09-01.csv-r-00001.gz
COOKIE_<account_name>_segments_map_2016-09-01.csv-r-00002.gz
IDFA_<account_name>_segments_map_2016-09-01.csv-r-00000.gz
IDFA_<account_name>_segments_map_2016-09-01.csv-r-00001.gz
IDFA_<account_name>_segments_map_2016-09-01.csv-r-00002.gz
HEM_SHA256_<account_name>_segments_map_2016-09-01.csv-r-00001.gz
HEM_SHA1_<account_name>_segments_map_2016-09-01.csv-r-00001.gz
HEM_MD5_<account_name>_segments_map_2016-09-01.csv-r-00001.gz
OTT_RIDA_<account_name>_segments_map_2016-09-01.csv-r-00001.gz
OTT_AAID_<account_name>_segments_map_2016-09-01.csv-r-00001.gz
OTT_IDFA_<account_name>_segments_map_2016-09-01.csv-r-00001.gz
OTT_AFAI_<account_name>_segments_map_2016-09-01.csv-r-00001.gz
OTT_MSAI_<account_name>_segments_map_2016-09-01.csv-r-00001.gz
Step 4: File Delivery and File Format
There are four options for file delivery, and corresponding file formats. With all options, Audience Studio provides the Data Receiver User Audience Segment Map files in CSV format. The file uses a Caret (^) as the delimiter and has 2 columns:
Partner User ID^SegmentsWhere:
the Partner ID is either the matched User ID via the cookie matching process described above or the IDFA and or AAID in the case of mobile app, or HEM, OTT, FPID device types.
If there are multiple segments per user ID the separator is Comma (,). Segment IDs are unique, alphanumeric segment IDs in Audience Studio.
Option 1: Incremental Refresh with Full Update
File format: UserID^SegmentID1,SegmentID2,SegmentID3
With this option, the partner specifies a refresh cadence X, and then Audience Studio will send incremental files for X-1 days and a full refresh every X days. On the incremental refresh days, there will be a corresponding COMPLETE.INCR file. On the full refresh days, there will be a corresponding COMPLETE.FULL file.
Note: Partners requesting this option must also provide the refresh cadence (eg: 30 days) for integration configuration, and we recommend it align to the user match recency supported by the partner if the system is heavily cookie-based.
Option 2: Incremental Refresh with Add/Remove/Final
File format: UserID^add:SegmentID1,SegmentID2;remove:SegmentID3;final:Segment1,Segment2,Segment4
This option has a different file format than the full and incremental options, but has the benefit of denoting which segments were added and removed. This may be helpful for partners who do not want a full refresh but who want to track which users are removed from which segments for the purpose of respecting consumer consent.
Option 3: Incremental Refresh (Standard)
File format: UserID^SegmentID1,SegmentID2,SegmentID3
In incremental pushes, each UserID line is a full refresh of segments for that user, which means that if if Day1 the UserID were in 3 segments, but Day2 the User dropped out of Segment3, the files would look like:
Day1: UserID^SegmentID1,SegmentID2,SegmentID3
Day2: UserID^SegmentID1,SegmentID2
In this option it is expected that the partner removes the user from Segment3.
Option 4: Full Refresh
File format: UserID^SegmentID1,SegmentID2,SegmentID3
With full refreshes, the file will contain the full list of users and segments.
Usage Reporting
Usage reporting must be provided on a monthly basis and may be delivered to an S3 location. Please see our article that describes the required monthly usage reporting requirements.
0 Comments