Introduction

The various AdTech integrations of Ad Alliance offer the possibility to transfer IDs that can be used for marketing purposes to the Tech & Data Stack and selected vendors. Depending on the technology used, the interfaces are defined differently:

Normalisation and Hashing of the eMail

There are two options for normalisation/hashing:

• The publisher transfers the unprocessed eMail address directly to the MoltenBundle and selects the type ‘raw’. Subsequently, the eMail address is normalised and hashed on the client side and only then passed into the further server-side processing chain.

• The publisher performs normalisation and hashing according to the following documentation and selects the type ‘hem’.

For normalisation, market-wide standards apply to ensure that the HEM generated by Publisher A matches that of Publisher B and Advertiser C:

• Spaces must be removed, both leading and trailing

• The eMail address must be converted to lowercase (JaneDoe@example.com -> janedoe@example.com)

• Only for g(oogle)mail.com addresses:

• Dots must be removed (jane.doe@gmail.com -> janedoe@gmail.com)

• “+” characters with an additional string before the @ must be removed (janedoe+home@gmail.com -> janedoe@gmail.com)

The eMail address normalised in this way must be hashed using SHA-256 (without salt).

Web-Integration via the MoltenBundle

Within the MoltenBundle, IDs are passed using the setIdentity method. This method accepts both the ID and the ID type.

Currently defined and permitted idtypes are:

• hem (for eMail addresses normalised and hashed by publishers)

• raw (for eMail addresses for which Ad Alliance should perform normalisation and hashing)

• netid (for the etpid)

• utiq (for the Adtechpass)

In order to ensure that, in the event of an opt-out, these sensitive IDs are deleted both in AdA’s Tech & Data Stack and at vendors, the clearIdentity method must be called once: