• Создана пользователем Неизвестный пользователь (sergey). Последнее обновление: дек. 21, 2015 Время чтения: 2 мин.

Вы просматриваете старую версию данной страницы. Смотрите текущую версию.

Сравнить с текущим просмотр истории страницы

« Предыдущий Версия 6 Следующий »

Revisions history

RevisionChanges
1.

Initial version

1.1Changed 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

  • Нет меток