Does your website use third-party services? Get GDPR compliant in minutes.
Try FlowConsentFree plan · 10-min setup
BlokID is a privacy first identity and consent solution for the advertising supply chain, marketed as safe for child directed inventory. It combines deterministic and probabilistic identity resolution with IAB TCF 2.2 signals and COPPA aware controls, so publishers and advertisers can run addressable and contextual campaigns while honouring GDPR, ePrivacy and US children privacy rules. Typical integration happens server side or through a prebid.js wrapper, which means it processes IP addresses, hashed emails and consent strings on behalf of the publisher.
BlokID is an identity and consent layer designed for the programmatic advertising supply chain. On the publisher side it resolves a visitor into a stable, hashed identifier (often from a logged in email, otherwise from a probabilistic signal combining IP address, user agent and first party cookies). On the advertiser side it exposes that identifier through prebid.js, server side header bidding adapters and a few DSP integrations, alongside the IAB TCF 2.2 consent string. The product is positioned as friendly to child directed and teen audiences because it can downgrade the identifier to a contextual only token when the publisher signals that the inventory is aimed at minors.
From a data protection perspective the publisher is controller, BlokID is processor under GDPR art. 28, and the downstream DSPs are independent or joint controllers depending on the contract. The CJEU IAB Europe ruling (C 604/22, March 2024) confirmed that the TCF consent string is personal data, which means every step of the pipeline must be covered by a valid legal basis and contractual safeguards.
A typical BlokID deployment writes a first party cookie on the publisher domain (commonly named bk_id or bkuid) holding the hashed identifier, a TCF related cookie mirroring the euconsent v2 string, and a short lived synchronisation cookie used to pair the BlokID id with partner ids during cookie syncs. When the publisher activates the cookieless mode, the identifier is held in localStorage instead, but the same data categories are processed. All of these storage operations require prior consent under ePrivacy art. 5(3) regardless of whether the data is technically personal data, because the access to terminal equipment is the trigger.
The only realistic lawful basis for BlokID on a public website or app is consent under GDPR art. 6(1)(a), collected through a CMP that supports IAB TCF 2.2. Legitimate interest is not available for ad personalisation following the EDPB guidance and the IAB Europe decision of the Belgian DPA. When the user is a minor below the digital age of consent (16 in Germany and the Netherlands, 15 in France, 14 in Italy and Spain, 13 in the United Kingdom and the US under COPPA), the publisher must obtain verifiable parental consent under GDPR art. 8 and, in the US, follow the FTC verifiable parental consent methods (signed form, credit card check, knowledge based authentication, video verification).
Refusal must be as easy as acceptance (CNIL deliberation 2020 091, EDPB guidelines 03/2022 on dark patterns), and consent must be granular per purpose. BlokID itself does not collect consent; it consumes the signal produced by the publisher CMP.
Get GDPR compliant in 10 minutes
Free plan available · No credit card required
BlokID operates from EU regions (typically Ireland) and US regions (typically Virginia). When the publisher uses the US endpoint, the hashed identifier, IP address and consent string leave the EEA. The transfer is covered by the EU US Data Privacy Framework (adequacy decision of 10 July 2023) for the US entity, and by Standard Contractual Clauses module 2 plus a transfer impact assessment for any onward transfer. Publishers should keep evidence of the active DPF certification (verifiable on dataprivacyframework.gov) and refresh the TIA at least annually, especially in light of the ongoing schrems III style litigation.
Sign the BlokID data processing agreement including TCF Annex; list BlokID and every downstream vendor in your privacy notice; run a DPIA under GDPR art. 35; configure your CMP to block BlokID before consent and to honour Global Privacy Control and the OptOut signals required by the California CPRA; verify that the BlokID tag never fires on pages flagged as child directed unless verifiable parental consent has been recorded; map the retention windows (90 days for the identifier, 13 months for TCF consent records under the CNIL recommendation); test the withdrawal flow end to end, including deletion from the BlokID identity graph within 30 days as required by GDPR art. 17.
If BlokID cannot be deployed in a compliant manner, publishers can fall back to fully contextual advertising solutions (Seedtag, Weborama Contextual, GumGum Verity), to publisher first party graphs limited to logged in users with explicit consent, or to clean room based audience activation that keeps raw identifiers on the publisher side. When discontinuing BlokID, ensure the processor confirms in writing the deletion of all identifiers and consent records, and update the IAB Global Vendor List subscription so that the BlokID vendor id is removed from your CMP within the next publication cycle.
Websites using BlokID must obtain user consent under GDPR regulations.
DPIA considerations
A Data Protection Impact Assessment under GDPR art. 35 is strongly recommended before deploying BlokID. The combination of large scale identity resolution, behavioural advertising and the explicit positioning toward child directed inventory triggers EDPB criteria 1 (evaluation/scoring), 3 (systematic monitoring), 4 (sensitive or highly personal data such as children data), 7 (data concerning vulnerable subjects) and 8 (innovative use of technology). The DPIA should document the legitimate need, describe the identity graph and TCF signal flow, evaluate re identification risk on hashed identifiers, justify any reliance on the EU US Data Privacy Framework, and define retention, deletion and parental consent workflows. Where the publisher operates an audience aimed at minors, the DPIA must reference the UK Children Code and, in France, the CNIL recommendations on minors online (deliberation 2021 069). Consultation of the supervisory authority under art. 36 may be required if residual risk remains high.
Sample consent text
We use BlokID, an identity and advertising consent service, to recognise your device, share a hashed identifier with our advertising partners and personalise the ads you see on this site. BlokID also relays your IAB TCF 2.2 preferences to those partners. If you are under the digital age of consent in your country (16 in much of the EU, 13 in the US under COPPA), we will only activate BlokID with verifiable parental authorisation. Your data, including a hashed email if you are logged in and your IP address, may be processed in the European Union and the United States under Standard Contractual Clauses and the EU US Data Privacy Framework. You can accept, refuse or withdraw your consent at any time from our cookie preferences panel.
Third-party domains contacted
blokid.comcdn.blokid.comid.blokid.comsync.blokid.comeu.blokid.comus.blokid.comCookies placed
| Name | Type | Duration | Purpose |
|---|---|---|---|
| bk_id | http_cookie | 90 days | First party cookie set on the publisher domain. Stores the hashed BlokID identifier used to recognise the visitor across sessions and to expose the id to prebid.js bidders and downstream DSPs. |
| bkuid | http_cookie | 90 days | Alternative first party identifier name used by some publisher integrations. Same purpose as bk_id, kept for backward compatibility with older prebid wrappers. |
| bk_consent | http_cookie | 13 months | First party cookie that mirrors the IAB TCF 2.2 euconsent v2 string so BlokID can verify on each request that the user has granted purposes 1, 3, 4 and 7. |
| bk_sync | http_cookie | 24 hours | Third party cookie set on blokid.com during cookie sync operations. Used to pair the BlokID identifier with partner SSP and DSP identifiers. |
| bk_optout | http_cookie | 5 years | Opt out cookie set on blokid.com when the user refuses or withdraws consent. Prevents the BlokID tag from setting any other identifier on subsequent visits. |
| bk_id_ls | local_storage | 90 days | localStorage key written when the publisher activates the cookieless mode. Stores the same hashed identifier as bk_id and is governed by the same consent requirement under ePrivacy art. 5(3). |
| bk_child_flag | http_cookie | 30 days | Internal flag indicating that the current page or audience has been declared child directed. Forces BlokID into contextual only mode and disables identity resolution. |
| bk_session | http_cookie | session | Short lived session cookie used for request signing and replay protection on the BlokID identity API. Expires when the browser tab is closed. |
BlokID places tracking cookies for advertising — comply with GDPR using FlowConsent.
A standard BlokID deployment writes a first party cookie on the publisher domain, typically named bk_id or bkuid, which stores a hashed identifier valid for up to 90 days. A second first party cookie mirrors the IAB TCF 2.2 consent string (euconsent v2). When cookie syncs are enabled, a short lived third party cookie on the blokid.com domain (often bk_sync) lasts a few minutes for partner pairing. In cookieless mode, the identifier moves to localStorage but the same logic applies. ePrivacy art. 5(3) requires consent for every one of these storage operations, even when stored in localStorage.
Yes. BlokID processes identifiers for advertising personalisation, which under GDPR art. 6(1)(a) and the IAB Europe ruling of the Belgian DPA can only rely on consent. The tag must remain blocked by the CMP until the user gives a freely given, specific, informed and unambiguous opt in, with refusal made as easy as acceptance per CNIL deliberation 2020 091 and EDPB guidelines 03/2022. Consent must be re collected after 13 months or whenever the purposes or vendors materially change.
Consent under GDPR art. 6(1)(a) is the only viable basis for identity based ad personalisation. Where the user is under the local digital age of consent (16 in Germany and the Netherlands, 15 in France, 14 in Italy and Spain, 13 in the UK), verifiable parental consent under GDPR art. 8 is mandatory. For users under 13 in the US, COPPA applies and the publisher must use one of the verifiable parental consent methods accepted by the FTC (signed form, credit card, knowledge based authentication, video verification). BlokID has a child directed mode that disables identity resolution and keeps only contextual signals; using it does not replace the need for parental consent when behavioural advertising is intended.
Yes when the publisher integrates the US delivery endpoint. Hashed identifiers, IP addresses and TCF consent strings are transferred to BlokID infrastructure in the United States (Virginia region). The transfer relies on the EU US Data Privacy Framework adequacy decision of 10 July 2023 for the certified US entity, supplemented by Standard Contractual Clauses module 2 and a transfer impact assessment for any onward transfer to sub processors. The certification must be checked on dataprivacyframework.gov and renewed annually. Publishers operating only on EU traffic should pin the integration to the EU endpoint and document this in the record of processing activities.
In almost every case yes. BlokID triggers at least five of the nine EDPB criteria for mandatory DPIA: evaluation/scoring, systematic monitoring, sensitive or highly personal data (children), vulnerable data subjects and innovative technology. The CNIL list of processing operations requiring a DPIA (2018 update) explicitly cites profiling for advertising. The DPIA must cover the identity graph, TCF signal flow, retention windows, withdrawal and deletion workflows, parental consent verification, and the EU US transfer. If residual risk remains high, prior consultation with the supervisory authority under GDPR art. 36 is required before go live.
There are three common patterns. First, a client side prebid.js wrapper loads the BlokID userId module, which reads or sets the bk_id cookie and exposes the identifier to the bidders. Second, a server to server integration calls the BlokID identity API from the publisher edge, which is preferred for performance and for keeping the identifier off the client. Third, a tag manager template fires the BlokID pixel only after the CMP grants TCF purposes 1, 3, 4 and 7. In all three cases, the publisher must wire the consent gating in the tag manager or in the prebid consentManagement module to prevent any network call before opt in.
For child directed inventory, fully contextual solutions are the safest option (Seedtag, Weborama Contextual, GumGum Verity, Illuma). For logged in audiences, a first party identity graph activated through a clean room (LiveRamp ATS, InfoSum, Habu) keeps raw identifiers on the publisher side. Publishers serving the US market can also consider Universal ID 2.0 with strict opt in flows. None of these alternatives removes the need for a CMP and a documented DPIA, but they reduce the cross border transfer and minors exposure that drive the BlokID risk profile.
List BlokID by name in the cookies section, describe the bk_id, bk_sync and TCF cookies with their retention (90 days for bk_id, session for bk_sync, 13 months for the TCF consent record), and reference IAB TCF 2.2 purposes 1, 3, 4 and 7. Update the third party recipients table to include the BlokID US entity and add the EU US Data Privacy Framework link. In the CMP, register the BlokID Global Vendor List id, enable the vendor only after explicit opt in, and link to the BlokID privacy notice. Republish the cookie policy with a version date so users can see the change history required by EDPB guidelines on transparency.