Publisher Zenith ID activation with Novatiq

Novatiq enables publishers to activate a session or multi-session based ID for telco network verification and consistent user recognition, replacing the third-party cookie with a privacy-safe, scaled, alternative.

Novatiq calls this service Zenith ID. The Zenith ID service enables the creation of a consented user graph to recognise repeat users of websites and apps, either for a single or multiple domains within a publisher group, which is communicated to the publisher data environment for robust first-party data profiling and analytics.

Consent

To use the Zenith ID service the publisher is required to gather consent from the user for the telco network verification. Consent requirements vary by regulatory regime and may be either implied or explicit.

If consent is implied, Novatiq require confirmation of consent and the validity period to be sent as part of the Zenith sync call.

If consent is explicit, Novatiq require confirmation of consent using the TCF String, or other consent management platform response.

When using TCF the string needs to contain:

• the Novatiq vendor code (1119), illustrating Novatiq as an approved vendor;
• the Novatiq consent purposes – currently TCF purposes 1, 7 and 10. These may be revised from time to time and will be updated accordingly.

A sample TCF String can be created and tested here: https://www.iabgpp.com/#

• Simply select tcfeu and then [1119 Novatiq] from the Vendor Consent list and the correct Purpose Consents (1, 7, 10) to generate the String.

Once the TCF String has been validated against the Novatiq requirements, the TCF String generation must be automated and included within each Zenith ID sync call.

Activation for Zenith ID consists of 2 functions:

1. Sync call to Novatiq

When a user visits the website or app an existing UUID either needs to be retrieved from local storage or needs to be generated for the session. If a new UUID is generated it needs to be added to local storage post creation. The UUID can be a first-party cookie or a publisher specific ID used for a single or multiple sessions, with validation time limits determined by the publisher.

The UUID generated is then sent to the Novatiq Zenith ID service:

https://spadsync.com/partner/zenithid=<zenith_id>&brandid=<brand_id>&consent=<consent>&tcf=<tcf_string>&altids=<alt_ids>

Along with:

1. the UUID – the first-party cookie or generated random ID;
2. the assigned Novatiq brand ID;
3. the consent string and validity period, when it expires in seconds (unix time);
4. any alt IDs on the page that can be used to help map the user when they are offnet.

Details of the sync call structure can be found in Appendix 1, Section 1, below.

The sync call response for the Zenith ID service is sent to the publisher backend data repository.

2. Sync call response to the publisher

When Novatiq receives a Zenith ID sync call from a publisher a lookup is performed to determine if the ID has already been recorded against the unique user.

If no Zenith ID already exists, Novatiq will record the initial Zenith ID for the user against the Brand ID and the Novatiq response to the publisher will simply be the same Zenith ID as the one sent in the sync call, indicated by the ‘Zenith ID’ parameter.

If the same Zenith ID already exists the Novatiq response to the publisher will simply be the same Zenith ID as the one sent in the sync call, indicated by the ‘Zenith ID’ parameter.

If the Zenith ID is different for the same user the Novatiq response to the publisher will contain the Zenith ID sent in the sync call in the ‘Zenith ID’ parameter and the previous Zenith ID, plus other associated titles Zenith IDs, in the ‘Link Zenith IDs’ parameter.

If alt IDs are sent in with the Zenith ID they are used for off-net user mapping and therefore it is encouraged that any other IDs be included in the sync request under the altd ID list.

The following error codes will be sent in the ‘error’ parameter if the sync call sends missing or invalid data:

• 1 – represents missing or invalid BrandID
• 2 – represents missing or invalid Zenith ID
• 3 – represents missing or invalid consent for the Zenith ID
• 4 – represents failed TCF validation
• 5 – represents failed altID consent validation

Example sync call responses are detailed in Appendix 1, Section 1, below.

Appendix – Sample call flows for Zenith ID activation

Sync call

Request template:

https://<domain>/partner?zenithid=<zenithid>&brandid=<brandid>&consent=<consent>&tcf=<tcf_string>altids=<altids>
https://spadsync.com/partner?zenithid=e6feeb18-1c70-4263-8ada-cf4c93304f7c&brandid=pnov02&consent=1757172653&tcf=&altids=abc
This contains:

    zenithid:   A randomised UUID

    brandid:    Assigned by Novatiq

    consent:    Consent validity period (when it expires), in seconds (unix time)

    altids:     Any altids on the page that can be reused to help map the user offnet.
An example response would be:

{

    "status": 404,

    "zenithid": "e6feeb18-1c70-4263-8ada-cf4c93304f7c",

    "linkids": [],

    "error": ""

}
Detailed consent sync response description
Response template:

{“status”:”<status>”,“zenithid”:“<Zenith ID>“,“linkids”:[<Link Zenith ID1>,<Link Zenith ID2>] ,”error”:”<message>”}
HTTP 200 OK

<status> - status of request

    200 - One of provided IDs was found

    400 - Validation failed

    404 - None of provided IDs were found
<Zenith ID> - Zenith ID that is to be used by the Brand/Publisher
<Link Zenith IDs> - list of other Zenith IDs to be used for Brand/Publisher to link to the Zenith ID
<message> - error code to represent error scenario:

    1 - represents missing or invalid BrandID

    2 - represents missing or invalid ZenithID

    3 - represents missing or invalid Consent for the ZenithID

    4 - represents failed TCF validation