Cookies policy and user consent

1) Why do I need a cookie policy

A cookie policy is a transparent description of what you collect, why, for how long, who you share with, and how to manage consent. For iGaming/fintech, this is critical due to the sensitivity of the data, the requirements of regulators and partners (payment providers, advertising networks, affiliates).

• Legality (compliance with GDPR/ePrivacy, CCPA/CPRA, LGPD, etc.).
• Transparency and control for the user (opt-in/opt-out).
• Risk management (fines, ad platform blocks, loss of trust).
• Stable metrics (banner conversion, marketing impact).

2) Categories of cookies/trackers (recommended taxonomy)

Note: mobile app SDKs/pixels also fall into these categories.

3) Banner and preference center (UX patterns)

• Clear buttons: "Accept All," "Reject All," "Customize" (equal visibility).
• Short announcement + link to detailed policy.
• Instant activation of settings (do not postpone).
• Do not block access to mandatory functionality.

• Granular toggle switches by category and (optional) by vendor.
• Save selection with timestamp, display status.
• Ability to change selection at any time (link in footer/profile).
• Separate sections: GPC/" Do Not Sell or Share," Limit Sensitive Data (for CA), Withdrawal of consent.

4) Consent Management Platform (CMP): features

Rendering banner and preference center (web + mobile SDK).
Consent log (policy version, category, vendor, time, region).
Rules geotargeting (EU/California/Brazil, etc.).
Integration with the tag manager: blocking tags until consent (prior consent).
API for applications and server systems (transfer of consent status).
Support for Global Privacy Control (GPC) and forced disabling of sharing/marketing when a signal is received.

5) Jurisdictions and Differences (Brief)

EU/EEA (ePrivacy + GDPR): opt-in for analytics/marketing; "mandatory" can be without consent. Need an informed choice, easy to change/withdraw.
California (CCPA/CPRA): opt-out rights from "sale" and sharing (behavioral advertising); GPC mandatory; ссылка «Do Not Sell or Share My Personal Information». For children <16 - opt-in.
Brazil (LGPD): similar principles: transparency, legal grounds; consent for marketing trackers, recall rights, portability, removal.

6) Architecture for turning on/blocking trackers

1. Pre-load guard: before obtaining consent, we load only mandatory scripts.
2. Tag Manager integration: mark each label with a category; activate after the CMP signal.
3. Server-side analytics (desirable): reduce the amount of personal data in the browser, centralize masking.
4. Mobile SDK gating: SDK initialization strictly after consent status; update on change.
5. Affiliate pixels: firing only when agreeing to marketing/attribution; server postback preferred.
6. Logs and audit: we record what and when was activated, on what basis.

7) Transparency and policy content

1. What cookies/SDKs are and why they are needed.

2. Categories and objectives (table).

3. Full list of cookies/SDKs used: name, provider, purpose, shelf life, type (1st/3rd party).

4. Processing bases (consent/LI/contract) and management methods.

5. GPC and regional rights (opt-in/opt-out, "Do Not Sell or Share," "Limit Sensitive Data").

6. Retention periods and criteria.

7. Transfers to third parties and to other countries (general protection mechanisms).

8. How to revoke/change a selection; DPO/support contacts.

9. Last updated date and version.

8) Storage and minimization

Retention Schedule: for each category - term (for example, analytics 13 months, marketing 6-13 months, functional 6-12 months).
Minimization: Reduce fields to necessary; for analytics, aggregation and aliasing.
Dev/Stage: do not use real identifiers; Use "dummy" data or masking.

9) GPC и «Do Not Sell or Share»

When receiving a GPC, automatically turn off sharing/marketing and log it.
A separate link in the footer: "Do Not Sell or Share My Personal Information" - for users in the USA (California).
In the Preference Center, display that GPC is active and which categories are therefore unavailable.

10) Examples of wording (ready-made fragments)

• "We use cookies to ensure the operation of the site, as well as for analytics and personalized advertising. Click Accept All or set up categories. You can change the selection at any time"

• "We process aggregated metrics of attendance and events. Analytics cookies are only placed with your consent. Shelf life - up to 13 months"

• "Marketing cookies allow you to display personalized ads and measure their effectiveness. You can opt out at the preference center or via GPC. If refused, we will not post such files and will restrict the transfer of data to third parties"

11) Metrics and quality control

Consent Rate (total, by region/source).
Reject Rate and Adjust Rate (user changes settings).
Time-to-Consent.
GPC Honor Rate (how many sessions are processed correctly).
Post-Consent Firing Accuracy.
Impact on Conversion (before/after - registration, deposit, FTD).
Incident Rate (unauthorized firing, ID leaks).

12) Checklists for implementation

Policies and texts

• Short banner with "Accept All/Reject All/Customize."
• Cookie policy with categories/vendors/deadlines tables.
• "Do Not Sell or Share..." link (for the US) and the GPC section.
• Updates the date and version each time you change it.

Technique and tags

• CMP is connected before any non-required tags.
• Tag manager blocks firing until consent (prior consent).
• Server analytics and affiliate postbacks where possible.
• Logs of agreement with region, version, time.

Operations and control

• Geo-recognition and different rules (EU/US/Brazil).
• GPC and opt-out scripting tests.
• Quarterly vendor/SDK list audit.
• Support training (how to help with consent changes).

13) Frequent mistakes and how to avoid them

Download analytics/marketing prior to consent → use prior-blocking and server side.
Uneven visibility of buttons → increases the risk of complaints/fines.
→ divide the confusing categories by goals, not by vendor names.
No GPC → nonconformance for USA (CA).
The absence of consent logs → difficult to prove legality.
Irrelevant vendor lists → automate audits and updates.

14) Matrix "Category → Basis → Action by Region"

15) Section template in your Policy (skeleton)

1. Operator/DPO definitions and contact details.
2. Categories of cookies and goals (table).
3. Vendor/SDK list with purpose and retention period.
4. How to manage consent (banner, center, GPC, links in browsers).
5. Regional rights: EU (opt-in/withdrawal), USA (opt-out/" Do Not Sell or Share "/GPC), Brazil (withdrawal of consent/rights of the subject).
6. Transfers to third parties and other countries (general protection measures).
7. Policy updates, date and version.

16) Implementation Roadmap (6 steps)

1. Tracker map: inventory of cookies/SDK/pixels, goals, vendors, deadlines.
2. CMP: selection, integration with tag manager and mobile SDKs, geo-rules.
3. Texts: banner, preference center, cookies policy, GPC/" Do Not Sell or Share" sections.
4. Technical circuit: prior-blocking, server analytics/postbacks, consent logs.
5. Test plan: Banner A/B, firing regressions, GPC/children/recall scenarios.
6. Operations: quarterly audit of vendors/deadlines, metrics report to management.

Result

A strong cookie policy is not only a banner: it is an architecture of consent, transparent categories and deadlines, the correct tag blocking technique, GPC support and clear interfaces for changing choices. By embedding these elements in your product and operations, you'll meet cross-jurisdictional requirements, mitigate risk, and maintain conversion and user trust.