Skip to main content

Attribute Sync Service

Introduction

The Data Sync Service offers implementers the option to store items on the Adhese server, that can be used for inventory and campaign insights as well as targeting. The storage can be linked to any kind of identifier as per configuration.

Server Side Memory

The memory service allows an implementer to save certain data points linked to a unique key. They key can be either a user' id, only allowed with explicit consent from the user, or any other non-personal key (a DOOH device ID for example).

The event is a string that will be saved and reported exactly as sent in. It can be completed with a human readable label in the Adhese inventory configuration.

The third parameter of the memory service is optional and indicates the time-to-live of the saved data point. When no value is passed, the default of 14 days will be applied.

https://ads-[customer].adhese.com/usersync/handlers/[service_handler]/user_sync?id=[event1],[event2]&u=[userid]&ttl=[expiration_in_minutes]

Example

https://ads-[customer].adhese.com/usersync/handlers/ec_view/user_sync?id=pricewatch&u=123abc&ttl=20160

Example with multiple events

https://ads-[customer].adhese.com/usersync/handlers/ec_view/user_sync?id=pricewatch,laptop,macbook&u=123abc&ttl=20160

Removing Data for a Key or User

All data stored in Redis will expire after a given time. However, for multiple reasons, the Right to be Forgotten being one of the most important ones, it is also necessary to provide a way to remove the stored data at the request of the rights holder (the end user).

For this purpose, you can simply call the user sync service with the user ID or key you want the data to be removed for. The service will remove all data stored for that key and then remove the key itself as well.

Example

https://ads-[customer].adhese.com/usersync/handlers/ec_view/user_sync?iu=123abc

User sync for Open Market OpenRTB

A very specific application of the Data Sync Service can be used for supporting the OpenRTB User Sync process.

The User Sync process attempts to match P users with SSPs users. We recommend to sync users once every day, at the first opportunity.

The User Sync service is triggered by Adhese directly on the client, and allows the SSP to connect to the client and pass the resulting user id to Adhese.

According to the setup, a simple or complex workflow is available. The complex workflow leads to a 1st party user sync cookie, the simple workflow leads to a 3rd party user sync cookie.

**User Consent** This application of the sync service depends on a cookie that contains a unique ID. Users need to be informed about this and give consent prior to calling the service. Adhese has the contractual right to audit the use of this service to ensure it is legally implemented.

Simple workflow

  1. The user navigates to newz.zz

  2. Browser calls SSP endpoint, eg: https://ssp.com/sync?partner=adhese

  3. The SSP redirects to user sync endpoint

  4. Browser calls Adhese user sync endpoint, eg: https://user-sync.adhese.com/handlers/ssp/user_sync?u=IH3D8DXL-20-KV8Y

  5. We issue a cookie: Set-Cookie: ssp_uid=IH3D8DXL-20-KV8Y; Domain=.adhese.com; Expires=Fri, 25-Dec-2024 09:57:40 GMT; Path=/

  6. Browser requests an ad on https://ads-adhese.com/ad/sl_foo_-bar

  7. We read ssp_uid cookie to send it over the SSP’s API

Complex workflow for 1st domain implementations

It's more complicated if a publisher serves on it’s own domains, no calls are made to *.adhese.com

  1. The user navigates to publisher-domain.com

  2. Browser registers request domain with Adhese user sync discovery, eg: https://user-sync.adhese.com/handlers/ssp/user_sync_discovery?domain=adhese.publisher-domain.com&protocol=https

protocol query parameter is optional, it defaults to https

  1. We read the domain parameter

  2. We issue a cookie: Set-Cookie: user_sync_domain=adhese.publisher-domain.com;Path=/;Expires=Fri, 25-Dec-2024 10:16:23 GMT

  3. Browser calls SSP endpoint, eg: https://ssp.com/sync?p=publisher

  4. SSP redirects to user sync discovery

  5. Browser calls Adhese user sync discovery, eg: https://user-sync.adhese.com/handlers/ssp/user_sync_discovery?u=IH3D8DXL-20-KV8Y

  6. We read the user_sync_domain cookie

  7. We redirect the call to user sync endpoint running on the correct domain

  8. Browser calls Adhese user sync endpoint, eg: https://adhese.publisher-domain.com/handlers/ssp/user_sync?u=IH3D8DXL-20-KV8Y

  9. We issue a cookie: Set-Cookie: ssp_uid=IH3D8DXL-20-KV8Y; Expires=Fri, 25-Dec-2024 09:57:40 GMT; Path=/

10. Browser requests an ad on https://adhese.publisher-domain.com/ad/sl_foo_-bar

11. We read ssp_uid cookie to send it over SSP’s API

Back to top