Surviving Cookie Deprecation: The Ultimate Guide to Server-Side Tracking

Introduction

For more than two decades, third-party cookies were the quiet workhorses of the web advertising ecosystem. They tracked users across domains, powered retargeting campaigns, connected ad impressions to conversions, and fed attribution models that marketing teams used to justify budget decisions. The entire digital advertising industry - worth hundreds of billions of dollars annually - was built on an infrastructure that most end users never saw and rarely understood.

That infrastructure is now being dismantled. Browser vendors, privacy regulators, and increasingly privacy-aware users have forced a reckoning. Apple's Intelligent Tracking Prevention (ITP), Mozilla's Enhanced Tracking Protection (ETP), and Google's eventual removal of third-party cookies from Chrome have set in motion an irreversible shift in how behavioral data can be collected on the web. For software engineers maintaining data pipelines, analytics stacks, and marketing infrastructure, the question is no longer whether to adapt but how - and how quickly.

This guide is written for engineers and technical leaders who need to understand server-side tracking not as a marketing buzzword but as a genuine architectural pattern with real trade-offs. We will examine why client-side tracking is degrading, how server-side tracking works at a systems level, how to implement it in a production environment, and what pitfalls to avoid when making the transition.

The Cookie Deprecation Landscape

A Brief History of the Problem

Third-party cookies were never designed for tracking at the scale the industry eventually demanded. They were a convenience feature introduced in the early 1990s that became the default mechanism for persistent cross-site user identification. For years, the privacy implications were largely ignored because the technology was invisible to end users and regulators had not yet caught up.

That changed dramatically with the introduction of GDPR in Europe in 2018, followed by CCPA in California in 2020, and a cascade of similar regulations globally. These frameworks did not explicitly ban cookies, but they introduced consent requirements that fundamentally changed how tracking data could be collected and processed. Simultaneously, browser vendors began taking unilateral action. Safari's ITP, first introduced in 2017 and progressively tightened through subsequent releases, began limiting the lifetime of third-party cookies and eventually cookies set via JavaScript. Firefox followed with similar protections. These changes came before any regulatory requirement - they were product decisions driven by competitive differentiation and user trust.

Where Google Chrome Stands

Google's position has been more complex. As the owner of the dominant browser and the dominant digital advertising platform, Google had conflicting incentives. Their Privacy Sandbox initiative, announced in 2019, proposed replacing third-party cookies with a set of browser-native APIs designed to support ad targeting and measurement without exposing individual user identities to third parties. After multiple delays, extensions, and industry pushback, Google announced in 2024 that rather than deprecating third-party cookies entirely, they would introduce a user-choice prompt in Chrome - allowing users to opt into or out of cross-site tracking.

This does not mean the problem disappears. A significant and growing percentage of Chrome users will opt out. ITP and ETP continue to apply to Safari and Firefox, which together account for a meaningful share of global browser usage. And regulatory pressure continues to tighten, especially in Europe. Engineers who assume that Chrome's revised stance gives them breathing room are misreading the trajectory. The direction is clear: client-side, cookie-based tracking is losing coverage, accuracy, and legal standing across the board.

How Client-Side Tracking Works - and Why It's Failing

The Classic Client-Side Model

In the traditional model, a marketing pixel - a small JavaScript snippet - is loaded directly in the user's browser. When a user visits a page or completes an action like a purchase, the pixel fires an HTTP request to a third-party tracking server (Google Analytics, Meta Pixel, LinkedIn Insight Tag, etc.). That request includes a cookie identifier, event data, and contextual metadata. The third-party server records the event, associates it with the user's persistent profile, and makes it available for attribution, audience building, and ad delivery.

This architecture has a deceptively simple surface. Drop a <script> tag into your HTML, configure a few event triggers in a tag manager, and you have a functional analytics pipeline in hours. The appeal is real: no backend infrastructure to maintain, no data storage to manage, and a vendor-hosted dashboard that marketing teams can operate independently. For years, the trade-offs of this model - vendor lock-in, data accuracy concerns, privacy implications - were considered acceptable because the alternative was significantly more engineering effort.

Why It's Breaking Down

The failure of client-side tracking is not a single event; it's a slow degradation across multiple dimensions. Browser-level restrictions reduce the lifetime of first-party cookies set via JavaScript (Safari limits these to seven days under ITP, with same-site and cross-site tracking blocked for third-party origins). Ad blockers, which are now used by a substantial minority of web users, block tracking pixels and analytics scripts at the network level - often before they even execute. Content Security Policies (CSPs) configured by security-conscious engineering teams can inadvertently block tracking tags. Consent management platforms (CMPs), when properly implemented, prevent tracking scripts from loading for users who have not consented, introducing systematic gaps in data coverage.

The cumulative effect is significant data loss. Studies and audits conducted by analytics practitioners have found that client-side analytics tools routinely undercount conversions, misattribute traffic sources, and produce session data that diverges significantly from server-side logs. For engineering teams responsible for data integrity, this is a correctness problem, not just a business problem. Attribution models built on incomplete data produce incorrect signals that propagate downstream into budget decisions, audience targeting, and product strategy.

Server-Side Tracking: Architecture and Core Concepts

The Core Idea

Server-side tracking shifts the responsibility for sending data to analytics and marketing platforms from the user's browser to your own backend infrastructure. Instead of the browser firing a pixel directly to Google or Meta, your server receives the event, enriches it with server-side context, and then forwards it to the relevant downstream platforms via server-to-server API calls. The browser never communicates directly with the third-party tracking domain.

This architectural shift has profound implications. First, ad blockers cannot intercept a request that never leaves your server. Second, because you control the infrastructure that makes the downstream API calls, you can manage data retention, apply pseudonymization or anonymization before forwarding, and maintain an audit trail for compliance purposes. Third, server-side cookies set via Set-Cookie headers are first-party cookies that are not subject to the same ITP restrictions as JavaScript-set cookies - they respect the full browser-defined cookie lifetime. Finally, because your server has access to backend context (authenticated user IDs, order data, CRM records), you can enrich events with information that is simply not available in the browser.

Key Components of a Server-Side Tracking Architecture

A production server-side tracking system has several distinct layers. The event collection layer is the entry point: your frontend sends events to an endpoint you own, typically using a lightweight JavaScript library or a direct HTTP call. The event processing layer validates, enriches, and normalizes events before they are forwarded. The forwarding layer translates normalized events into the proprietary formats expected by downstream platforms (Google's Measurement Protocol, Meta's Conversions API, etc.) and handles retries, rate limiting, and error handling. The storage layer persists raw and processed events for debugging, replay, and compliance. Finally, the identity layer manages user identifiers - maintaining the mapping between your first-party user IDs and the hashed or pseudonymized identifiers expected by ad platforms.

Implementing a Server-Side Tracking Pipeline

Building a First-Party Event Endpoint

The first practical step is creating an endpoint on your own domain that your frontend sends events to. This endpoint must be fast (it's in the hot path of user interactions), reliable, and capable of handling high throughput. A common pattern is to use a lightweight HTTP handler that immediately acknowledges the request and enqueues the event for asynchronous processing.

The following TypeScript example shows a minimal Express.js endpoint that accepts events and publishes them to a message queue for downstream processing:

import express, { Request, Response } from "express";
import { z } from "zod";
import { publishToQueue } from "./queue-client";

const app = express();
app.use(express.json());

const TrackingEventSchema = z.object({
  eventName: z.string().min(1).max(100),
  eventTimestamp: z.number().int().positive(),
  sessionId: z.string().uuid(),
  userId: z.string().optional(),
  properties: z.record(z.unknown()).optional(),
});

type TrackingEvent = z.infer<typeof TrackingEventSchema>;

app.post("/collect", async (req: Request, res: Response) => {
  const parsed = TrackingEventSchema.safeParse(req.body);

  if (!parsed.success) {
    return res.status(400).json({ error: "Invalid event payload" });
  }

  const event: TrackingEvent = parsed.data;

  // Enrich with server-side context unavailable in the browser
  const enrichedEvent = {
    ...event,
    serverTimestamp: Date.now(),
    ip: req.headers["x-forwarded-for"] ?? req.socket.remoteAddress,
    userAgent: req.headers["user-agent"],
    referrer: req.headers["referer"],
  };

  // Publish asynchronously - do not block the response
  await publishToQueue("raw-events", enrichedEvent);

  // Acknowledge immediately to minimize browser-side latency
  return res.status(202).json({ status: "accepted" });
});

app.listen(3000, () => console.log("Event collector listening on port 3000"));

This pattern decouples event ingestion from event processing. The endpoint's only job is to validate the payload, attach server-side metadata, and hand the event off to a queue. All the complex work - enrichment, identity resolution, forwarding to third parties - happens asynchronously in a separate worker process. This ensures that tracking never adds latency to the user's critical path.

Forwarding to the Meta Conversions API

Once events are processed, they need to be forwarded to advertising platforms. Meta's Conversions API (CAPI) is one of the most important destinations for e-commerce and performance marketing use cases. The API expects events in a specific format and requires that personally identifiable information (PII) be hashed using SHA-256 before transmission.

import crypto from "crypto";
import fetch from "node-fetch";

interface MetaCapiEvent {
  eventName: string;
  eventTime: number;
  userData: {
    email?: string;
    phone?: string;
    clientIpAddress?: string;
    clientUserAgent?: string;
    fbp?: string; // Meta browser cookie
    fbc?: string; // Meta click ID
  };
  customData?: Record<string, unknown>;
  eventSourceUrl?: string;
  actionSource: "website" | "email" | "app" | "phone_call" | "other";
}

function sha256Hash(value: string): string {
  return crypto
    .createHash("sha256")
    .update(value.trim().toLowerCase())
    .digest("hex");
}

async function sendToMetaCAPI(
  pixelId: string,
  accessToken: string,
  event: MetaCapiEvent
): Promise<void> {
  const payload = {
    data: [
      {
        event_name: event.eventName,
        event_time: event.eventTime,
        action_source: event.actionSource,
        event_source_url: event.eventSourceUrl,
        user_data: {
          // PII must be SHA-256 hashed per Meta's requirements
          em: event.userData.email
            ? sha256Hash(event.userData.email)
            : undefined,
          ph: event.userData.phone
            ? sha256Hash(event.userData.phone)
            : undefined,
          client_ip_address: event.userData.clientIpAddress,
          client_user_agent: event.userData.clientUserAgent,
          fbp: event.userData.fbp,
          fbc: event.userData.fbc,
        },
        custom_data: event.customData,
      },
    ],
  };

  const response = await fetch(
    `https://graph.facebook.com/v19.0/${pixelId}/events?access_token=${accessToken}`,
    {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify(payload),
    }
  );

  if (!response.ok) {
    const error = await response.json();
    throw new Error(`Meta CAPI error: ${JSON.stringify(error)}`);
  }
}

Notice the SHA-256 hashing of email and phone before transmission. This is not optional - it is required by Meta's API contract, and it is also the minimum pseudonymization step required for GDPR compliance when sharing user data with a data processor. Your event processing pipeline should treat all PII handling as a first-class concern, not an afterthought.

Managing First-Party Cookies Server-Side

A critical advantage of server-side tracking is the ability to set first-party cookies from your server using Set-Cookie response headers. These cookies are not subject to ITP's JavaScript cookie restrictions and respect the full cookie lifetime you configure. The common pattern is to generate a persistent session identifier on the first visit and set it as a first-party cookie that your event collection endpoint can read on subsequent requests.

import uuid
import hashlib
from datetime import datetime, timedelta
from flask import Flask, request, make_response

app = Flask(__name__)

COOKIE_NAME = "_fp_uid"
COOKIE_MAX_AGE_DAYS = 365


def generate_user_id() -> str:
    """Generate a new pseudonymous first-party user identifier."""
    return str(uuid.uuid4())


def get_or_create_user_id(request_cookies: dict) -> tuple[str, bool]:
    """
    Returns (user_id, is_new_user).
    Reads existing cookie or generates a new one.
    """
    existing = request_cookies.get(COOKIE_NAME)
    if existing:
        return existing, False
    return generate_user_id(), True


@app.route("/collect", methods=["POST"])
def collect_event():
    user_id, is_new = get_or_create_user_id(request.cookies)

    event_data = request.get_json(silent=True) or {}
    event_data["first_party_user_id"] = user_id

    # ... publish event_data to processing queue ...

    response = make_response({"status": "accepted"}, 202)

    if is_new:
        # Set a server-side first-party cookie - not subject to ITP JS restrictions
        expires = datetime.utcnow() + timedelta(days=COOKIE_MAX_AGE_DAYS)
        response.set_cookie(
            COOKIE_NAME,
            value=user_id,
            max_age=COOKIE_MAX_AGE_DAYS * 86400,
            expires=expires,
            httponly=True,    # Inaccessible to JavaScript - reduces XSS exposure
            secure=True,      # HTTPS only
            samesite="Lax",   # Balanced CSRF protection
            domain=".yourdomain.com",
        )

    return response

The HttpOnly flag ensures this cookie is inaccessible to JavaScript, reducing XSS attack surface. The Secure flag ensures it is only transmitted over HTTPS. The SameSite=Lax attribute prevents the cookie from being sent on cross-site POST requests while still allowing it on top-level navigations. These are not optional security niceties - they are the baseline for any production cookie handling.

Identity Resolution Without Third-Party Cookies

The Identity Problem

The core value proposition of third-party cookies was cross-site identity - the ability to recognize that the same user who visited your website yesterday also visited a publisher's site this morning. Without that cross-site identifier, the entire retargeting and audience-building model breaks down. Server-side tracking solves the data collection problem but does not automatically solve the identity problem. You need an explicit strategy for user identification.

The most reliable identifier in a server-side model is an authenticated user ID. If your platform requires users to log in, you have a persistent, consistent identifier that survives browser changes, device switches, and cookie clearances. This ID should be your primary identity anchor. All events from authenticated sessions should be tagged with a pseudonymized version of this ID (a deterministic hash, not the raw database primary key) before being forwarded to third-party platforms. The hashed ID allows downstream platforms to perform matching without receiving your raw user database identifiers.

Probabilistic and Deterministic Matching

For unauthenticated users, you have two approaches to identity resolution. Deterministic matching relies on known signals - email addresses or phone numbers provided voluntarily by the user through newsletter signups, loyalty programs, or checkout flows. When a user provides their email, you can hash it and use it as a matching key with advertising platforms that maintain their own hashed email graphs (Meta's CAPI and Google's Enhanced Conversions both support this). This is powerful but limited to users who have explicitly provided contact information.

Probabilistic matching uses statistical signals - IP address, user agent, device fingerprint, behavioral patterns - to infer that multiple sessions belong to the same user. This approach is more controversial from a privacy perspective and increasingly restricted by regulation. GDPR's position on device fingerprinting as a form of tracking that may require consent even when no persistent identifier is stored should give engineers pause. A well-designed server-side identity system leans heavily on deterministic matching and treats probabilistic signals as supplementary signals for analytics aggregates rather than individual-level attribution.

Trade-offs and Pitfalls

Operational Complexity

The most significant trade-off of server-side tracking is operational complexity. You are now responsible for infrastructure that was previously vendor-managed. Your event collection endpoint must be highly available - downtime means data loss, and data loss means broken attribution. Your event processing workers must handle backpressure gracefully when downstream platforms rate-limit your requests. Your queue must be durable so that a worker crash does not cause events to be silently dropped. Your forwarding logic must handle API versioning as Google, Meta, and other platforms evolve their server-side APIs.

None of this is technically difficult for an experienced backend team, but it requires deliberate engineering investment. Teams that underestimate this complexity often end up with a fragile pipeline that loses data in non-obvious ways - which is arguably worse than the degraded-but-understood data loss of a purely client-side setup. The operational overhead is manageable with proper observability: instrument your event pipeline with metrics for ingestion rate, processing latency, queue depth, and forwarding success rates. Dead-letter queues for failed forwarding attempts are essential.

Deduplication Between Client-Side and Server-Side Events

A common mistake during the transition to server-side tracking is running both client-side pixels and server-side forwarding simultaneously without deduplication. Ad platforms like Meta and Google explicitly support this dual-signal model - they prefer to receive both the browser pixel event and the server-side event and use event ID matching to deduplicate them, resulting in a more accurate combined signal than either source alone. However, if deduplication is not configured correctly, platforms will count the same conversion twice, inflating your reported performance and distorting your attribution models.

The deduplication mechanism is straightforward in principle: each event must carry a unique event_id that is consistent between the client-side pixel and the server-side forwarding call. Your frontend generates this ID when the event occurs, includes it in the pixel call, and sends it to your server-side endpoint. Your server-side forwarder then includes the same ID in the API call to the platform. When the platform receives two events with the same event_id within the deduplication window, it counts them as one. This sounds simple, but it requires coordination between your frontend JavaScript, your tag manager configuration, and your server-side pipeline - and any mismatch in the ID generation or transmission breaks the deduplication logic silently.

Privacy Compliance Is Not Automatic

Server-side tracking is sometimes presented as a privacy-compliant alternative to third-party cookies. This framing is misleading. The mechanism of data collection (server-to-server vs. browser pixel) is orthogonal to the legal basis for collection. If you are collecting user behavioral data and forwarding it to advertising platforms, you almost certainly need explicit user consent under GDPR in the EU, even if that data never touches a third-party cookie. Moving tracking to the server does not change what data you are collecting or why - it only changes how.

Engineers should be particularly careful about the data minimization principle. Just because you have server-side access to a rich set of user attributes does not mean you should forward all of them to your analytics platforms. Design your event schema to capture only the signals genuinely necessary for your measurement objectives. Treat PII handling as a first-class concern at every stage of the pipeline, not as a compliance checkbox applied at the forwarding layer.

Best Practices

Design for Observability from Day One

A server-side tracking pipeline that you cannot observe is a liability. Before writing a single line of event forwarding code, invest in instrumentation. At minimum, you need metrics for: events received per second at your collection endpoint, queue depth and consumer lag, forwarding success rate per destination platform, and forwarding error rate categorized by error type (rate limit, authentication failure, schema validation failure, network timeout). Log every forwarding failure with enough context to replay the event. Implement dead-letter queues for events that cannot be forwarded after exhausting retries, and build tooling to inspect and selectively replay them.

This observability infrastructure pays dividends beyond debugging. When a marketing team reports that conversion data "looks wrong" - which will happen - you need the ability to trace a specific conversion event from browser collection through queue processing to platform confirmation. Without end-to-end traceability, you will spend days chasing phantom discrepancies.

Implement Consent-Aware Event Routing

Your event pipeline should be consent-aware at the routing level. When a user declines all cookies and tracking through your CMP, your server-side pipeline should still be able to receive the event (for aggregate analytics, fraud detection, and server-side logging that does not require consent), but it should not forward it to advertising platforms that use it for individual-level targeting. This requires encoding the user's consent state as part of the event payload and building routing logic in your processing layer that respects it.

A practical pattern is to define categories of event destinations - "analytics only," "advertising," "personalization" - and map each destination platform to one or more categories. The processing worker checks the event's consent flags against the destination categories before forwarding. This makes consent routing explicit, auditable, and easy to extend as your list of destination platforms grows.

Use Vendor-Managed SDKs as a Starting Point, Not a Ceiling

Several analytics and tag management vendors - including Segment, Rudderstack, and Tealium - offer server-side event processing frameworks that abstract away some of the integration complexity. These are legitimate starting points that can accelerate time-to-value. However, they introduce vendor dependency into your critical data infrastructure, and their abstraction layers can obscure important details about how events are formatted, deduplicated, and forwarded to each platform. Understand what these tools do under the hood before committing to them. Evaluate them on their data residency options (important for GDPR compliance), their support for dead-letter queues and replay, and their observability capabilities.

Audit Your Pipeline Regularly

Platform APIs change. Meta's Conversions API has gone through multiple versions. Google's Measurement Protocol for GA4 has its own evolving schema. Privacy regulations evolve and their interpretation by data protection authorities becomes clearer over time. A server-side tracking pipeline that is not actively maintained will degrade - not through dramatic failure but through quiet schema drift, deprecated API versions, and changing consent requirements. Build a maintenance calendar for your tracking infrastructure and treat API version upgrades with the same discipline you apply to dependency updates in your application code.

Key Takeaways

Start with a first-party event endpoint on your own domain. This single architectural change eliminates ad blocker interference and gives you control over the data flow. It is the foundation everything else builds on.
Set persistent identifiers via server-side Set-Cookie headers. A server-set HttpOnly, Secure cookie bypasses ITP's JavaScript cookie restrictions and gives you a durable first-party user identifier across sessions.
Implement deduplication by design, not as an afterthought. Generate a unique event_id in the browser for every event, pass it through your entire pipeline, and include it in every server-side API call to prevent double-counting.
Build consent routing into the event processing layer. Respect user consent choices at the forwarding stage. This is not just a compliance requirement - it is the architectural decision that keeps your pipeline legally defensible as regulations evolve.
Invest in observability before you invest in additional platform integrations. A measurable, debuggable pipeline serving three destinations is worth more than an opaque pipeline serving ten. Add destinations after you have confidence in your core infrastructure.

Analogies and Mental Models

Think of client-side tracking as mailing postcards through someone else's postal service. The postcards are visible to everyone who handles them, and you have no control over whether they arrive, who reads them, or how long they take. Third parties can intercept them at any point in the delivery chain, and the postal service can change its rules - or shut down entirely - at any time.

Server-side tracking is closer to operating your own courier service for the most important deliveries. You pick up the package at the source, you decide what information to include on the label, you choose which roads to take, and you get a delivery confirmation when it arrives. You bear the operational cost of running the courier service, but you gain control, reliability, and the ability to make informed trade-offs at every step.

This analogy also highlights why hybrid approaches make sense. For low-value, high-volume signals where data loss is acceptable, the public postal service (client-side pixels) is fine. For high-value conversion events where accuracy is critical, your own courier service (server-side forwarding) is worth the operational cost.

80/20 Insight

If you had to implement server-side tracking in the smallest possible increment that would produce the largest improvement in data quality, it would be this: implement server-side forwarding for conversion events only.

Purchase confirmations, lead form submissions, and subscription activations are the events that drive attribution, ROAS calculations, and audience seed lists for lookalike campaigns. They are also the events most damaged by client-side data loss, because they often occur on pages with aggressive CSPs, after long sessions where tracking cookies have expired, or on mobile devices where tracking is most restricted.

A targeted implementation that forwards only these high-value events server-side - while leaving page view and scroll tracking on the client-side - delivers the majority of the accuracy improvement with a fraction of the full implementation complexity. Start here, prove the value, and expand the pipeline incrementally.

Conclusion

The deprecation of third-party cookies is not a problem that can be solved with a configuration change or a new vendor relationship. It is an architectural shift that requires engineering investment in infrastructure you own and control. Server-side tracking is the most robust response to this shift - not because it bypasses privacy concerns, but because it gives you the control necessary to handle privacy requirements correctly while maintaining the data quality your business depends on.

The transition is not trivial. It requires building and operating new infrastructure, coordinating consent management across client and server boundaries, maintaining integrations with evolving platform APIs, and developing internal observability tooling that most teams do not currently have. But these investments compound. A well-built server-side tracking pipeline is more accurate than client-side tracking even without cookie deprecation, more maintainable, more compliant, and more resilient to the next wave of browser privacy changes - which will inevitably come.

The engineers who treat this moment as an infrastructure modernization opportunity rather than a crisis will emerge with measurement capabilities that are genuinely superior to what they had before. The engineers who wait will find themselves in an increasingly difficult position as data quality degrades and compliance exposure grows. The choice is not really between the old way and the new way. It is between building the new way deliberately, on your own terms, or having it forced upon you.

References

Meta Conversions API Documentation - Meta for Developers. Available at: https://developers.facebook.com/docs/marketing-api/conversions-api
Google Measurement Protocol (GA4) Documentation - Google Analytics Developer Guides. Available at: https://developers.google.com/analytics/devguides/collection/protocol/ga4
Google Enhanced Conversions Documentation - Google Ads Help. Available at: https://support.google.com/google-ads/answer/9888656
Apple Intelligent Tracking Prevention - WebKit Blog. Available at: https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/
Mozilla Enhanced Tracking Protection - Mozilla Support. Available at: https://support.mozilla.org/en-US/kb/enhanced-tracking-protection-firefox-desktop
Google Privacy Sandbox - privacysandbox.com. Available at: https://privacysandbox.com/
General Data Protection Regulation (GDPR) - Official EU Regulation text. Available at: https://gdpr-info.eu/
California Consumer Privacy Act (CCPA) - California Attorney General. Available at: https://oag.ca.gov/privacy/ccpa
HTTP Cookie RFC 6265 - IETF. Barth, A. (2011). HTTP State Management Mechanism. Available at: https://datatracker.ietf.org/doc/html/rfc6265
SameSite Cookie Attribute Specification - IETF Draft / Web Standards. Available at: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite
IAB Europe Transparency and Consent Framework (TCF) - IAB Europe. Available at: https://iabeurope.eu/transparency-consent-framework/
Rudderstack Server-Side Documentation - Available at: https://www.rudderstack.com/docs/sources/event-streams/sdks/
Segment Connections Documentation - Available at: https://segment.com/docs/connections/
EDPB Guidelines on the use of cookies - European Data Protection Board, Guidelines 05/2020. Available at: https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-052020-consent-under-regulation-2016679_en