Просмотреть исходный

Revisions history

Revision	Changes
1.	Initial version
1.1	Changed mobile DMP USER ID raw and md5 formats and hashing rules.

Basics

This document describes a generic way to upload segmented data to RTBSuite DSP for further targeting. The workflow is as follows:

DMP uploads data through SFTP protocol on RTBSuite servers
The data is represented as set of txt.gz files using tab separated format (below)
DSP starts using this data

File name format

The data should be stored in txt.gz files in following format:
[DMP ID].[DATE as yyyy-MM-dd_HH-mm-ss].[FILE ID].txt.gz
Where:

[DMP ID] a string id assigned to DMP partner
[DATE] date of file generation in specified format
[FILE ID] unique file id

Example:
the_dmp. 2015-07-15_12-00-00.632a0017-bbda-4be7-a5fe-6a2478b65c89.txt.gz

Data format

The first line of file should be a header and will always be ignored. The further line should follow the syntax below:
[DMP USER ID]<tab>[DSP USER ID]<tab>[SEGMENTS TO ADD]<tab>[SEGMENTS TO REMOVE]
Where:

[DMP USER ID] – DMP user id (could be empty)
[DSP USER ID] – DSP user id (could be empty)
[SEGMENTS TO ADD] – comma separated list of segments. Each segments should be an id or id:expiration timestamp (in UTC/milliseconds). Example "1,2,3" or "1,3,4: 1437061152368". If expiration time isn't given for segment a default expiration policy (configured per DMP) will be applied
[SEGMENTS TO REMOVE] – comma separated list of segments

Notes:

Only one of [DMP USER ID] or [DSP USER ID] should present

User ID format

For display (desktop inventory format) [DMP USER ID] or [DSP USER ID] could be any string that doesn't contain ':' character.
For mobile DMP USER ID each user id should have a prefix

Prefix	Meaning	Examples
m_raw	Raw advertiser id (iOS IDFA or Android Advertising ID). Case sensitive	Android m_raw:dec820aa-41ae-43e0-b3b1-19e2ab258233 iOS m_raw:C78B8B75-885A-4573-B394-CEB5B1337BA3
m_md5	MD5 hash of IDFA or Android ID. Hashing is done over string representation of UUID! After that hash is encoded to hex string. NOTE: md5 hashing is compatible with google AdX hashing	m_md5: 86d8638a89ae4a53a57746500f268bcc (hash of dec820aa-41ae-43e0-b3b1-19e2ab258233) m_md5: d03b31165b28e930419700bcba1cd7ab (hash of 0AAF2E9B-8237-66FE-4768-35EF193327CA) m_md5: 95a3c8be285dcb7b83a4a76f3bf4a4f6 (hash of 7D50A078-3388-8161-AC55-FFE718377953)
m_sha1	NOT SUPPORTED	NOT SUPPORTED

Cookie (user) matching

For matching DSP and DMP user ids DMP should support user matching aligned with RTBSuite DSP API. Depending of which side initiates matching/initiates syncs different workflows is applied. See table below:

	DSP Initiates Syncs	DMP Initiates Syncs
DMP Stores Matching	DSP calls: //dmp_url?...[DSP_USER _ID] DMP Stores Match	DMP calls //[RTBSuite domain]/p/cm/ [DMP_NAME]?u=[DMP_USER_ID] DSP Redirects to: //dmp_url?...[DSP_USER _ID] DMP Stores Match
DSP Stores Matching	DSP calls: //dmp_url?...[DSP_USER _ID] DMP Redirects to: //[RTBSuite domain]/p/cm/ [DMP_NAME]?u=[DMP_USER_ID] DSP Stores Match	DMP calls //[RTBSuite domain]/p/cm/ [DMP_NAME]?u=[DMP_USER_ID] DMP Stores Match

By default RTBSuite will support only DMP-side matching storage and both sync initiation options