First-Party Tag Relay (Kobico Relay) — Phase 2+

Status: Deferred — not v1 scope. v1 uses API-provisioned pixels/CAPI plus implementation guide. This doc captures the recommended later architecture, cloud choice, and cost bands for planning.

Problem

Client effort (target)

Not required: Separate CMP purchase before onboarding, Meta pixel, TikTok pixel, separate GTM publish per platform, client payment to a CMP vendor.

Loader delivery modes

Same manifest, modules, and relay backend for both modes. Third-party mode uses stricter QC — do not mark tracking green on parity with first-party without review.

Locked in ADR 0005.

Architecture options

A — Kobico Relay (preferred product path)

• Browser: thin loader collects page context, click IDs, consent, event_id
• Edge: TLS for client hostname, rate limit, WAF
• Relay: normalize vertical templates, dedup, hash PII, fan-out (same APIs as v1 CAPI relay)

B — Hosted server-side GTM (alternative SKU)

Same CNAME; origin runs GTM server container instead of custom relay. Industry-standard; heavier to automate multi-tenant.

Recommendation: Build A as default SKU; offer B only for GTM-mature clients.

k.js micro-module architecture

Locked: ADR 0005 — Pattern A bootstrap + cached chunks; hybrid Cloudflare edge + GCP Cloud Run origin.

Runtime flow

Module taxonomy

Rules: Local listeners depend only on k-core public API — no cross-imports between listeners. Each module ships as an immutable versioned URL with long edge cache. Marketing modules load only after marketing consent; analytics modules after analytics consent.

Tenant manifest (edge)

Resolved at onboarding and stored in edge KV/D1; referenced by bootstrap:

platform selects the primary regional adapter; vertical drives event names. Edge derives enabled_modules from plan SKU + platform + vertical — onboarding does not hand-pick ten flags.

Delivery pattern — Pattern A (default)

1. Browser loads k.js (bootstrap).
2. Bootstrap fetches manifest from edge (short TTL / ETag).
3. Loads k-core.js (static, globally cached).
4. Resolves consent (Kobico CMP default or external CMP bridge).
5. Lazy-loads optional modules (listener-global-shopify.js, listener-local-ikas.js, …).
6. Relay POST — first-party: same-origin on metrics.client.com; third-party: configured relay endpoint.

Not used for MVP: edge-stitched single file per tenant (Pattern B) or per-tenant CI bundles (Pattern C).

Phased module rollout

Relay ships incrementally — clients need not wait for every platform adapter:

Performance and cost budgets (planning)

Protects client PageSpeed / SEO and keeps edge transfer bounded at Growth scale (~50 tenants, ~10M req/mo — see Cost estimation).

API / scope compatibility

Relay fan-out uses the same endpoints as v1 — no special “server-side tagging scope”:

GTM Tag Manager API is only needed for option B (container publish) — not for Kobico Relay.

Consent management — required for Relay

Yes. If Kobico Relay sets first-party cookies and fans out events to Meta, TikTok, GA4, and Google Ads, consent must be enforced before non-essential processing. A DNS record and loader alone do not satisfy GDPR, UK GDPR, or KVKK — the relay becomes part of the client’s tracking stack and must respect visitor choice.

This is separate from portal consents (ToS, data-sharing, Meta OAuth) in onboarding provisioning spec §7. Relay needs website visitor cookie consent in addition.

Responsibility split

Relay must not treat server-side fan-out as a loophole: if marketing consent is denied in the browser, the relay drops or anonymizes ad-personalization payloads (CAPI with restricted parameters, no new marketing cookies).

Consent categories (default taxonomy)

Tenant config: consent_profile on tenant_registry — eea_strict | uk_strict | tr_kvkk | row_light (still document; no silent opt-in where law requires opt-in).

CMP deployment modes (pick per tenant at onboarding)

Product rule: Onboarding must not require “purchase a CMP elsewhere, then return.” Default path is Mode 2 (Kobico CMP included). Modes 1 and 4 are opt-in via portal Consent provider selector.

Default recommendation: cmp_mode = kobi_cmp at Relay enablement. Mode 1 when client BYO CMP is detected or selected. Mode 4 when leadership closes a bundled global CMP offer (partnerships).

Consent banner game plan (implementation)

Phase A — Tenant config (onboarding Relay SKU)

Store website consent config on onboarding_record.tracking_relay; link to portal consent_record for contractual data-sharing — two layers, one audit trail.

Phase B — Loader (k.js) behavior

1. Default denied for analytics + marketing in EEA/UK until CMP fires consent_update.
2. Expose window.kobiConsent bridge for client CMP integrations.
3. Set Google Consent Mode v2 defaults (ad_storage, analytics_storage, ad_user_data, ad_personalization) before any hit.
4. Set first-party cookies only when category allows (e.g. _fbp only if marketing granted).
5. Queue events in memory until consent known; flush or purge on deny.
6. Attach consent_snapshot (categories + CMP version + timestamp) on each relay POST — relay logs, does not re-interpret legal text.

Phase C — Relay server gates

Optional: persist anonymized consent metrics to BigQuery (relay_consent_events) for ops — not a substitute for CMP records.

Phase D — Platform-specific signals

Pin exact parameter names at implementation — platform docs change; QC checker validates consent fields present for EEA tenants.

Phase E — Client CMP integration cookbook (Mode 1)

Document in implementation guide v2 — one snippet per major CMP:

Kobico maintains a compatibility matrix; unknown CMP → default Kobico CMP or HITL onboarding step — never block Relay on external CMP procurement.

Global CMP partnerships and bundled resell

Partnership program (active — discuss with leadership / board): Pursue formal partnerships with global CMP vendors (Cookiebot, OneTrust, iubenda, CookieYes, and peers) for portfolio pricing, co-marketing, TR/EU localization, and support escalation. Partnership is on the table alongside Kobico CMP — not instead of it.

If a vendor declines partnership, Kobico may still bundle that CMP at no incremental client charge (Pattern: portfolio seat allocation) rather than sending clients to procure consent tooling separately. Model fully loaded CMP cost (~€2–8/site/mo at SMB tiers) into existing €5–15/site/mo Relay planning band.

Exec checklist (partnerships): target vendor list, DPA/subprocessor terms, white-label vs co-brand, TCF registration responsibilities, TR locale coverage, rev-share vs flat portfolio fee.

Phase F — Kobico CMP (Mode 2) MVP scope

Banner UI: small bundle served from same subdomain as k.js; theme tokens from tenant brand colors.

Phase G — Ops, QC, and HITL

Add ONB-14 (future): Relay enabled but privacy_policy_url or consent_profile missing → block tracking_relay.active.

Consent + engineering cost add-on

Infra: Kobico CMP adds negligible cost (static assets on same edge as k.js). Third-party CMP seats absorbed in bundle when cmp_mode = kobi_bundled_cmp — see Global CMP partnerships.

Cloud provider recommendation

Default: GCP for compute + Cloudflare for edge (hybrid).

Why not AWS / Azure as primary?

• Rest of Kobico Digital Ads is GCP-illustrative (Vertex, Cloud Run, BQ).
• Splitting relay to Lambda@Edge or Azure Front Door adds second billing, IAM, and runbooks for marginal savings at pilot scale.
• Revisit only if entire Kobico platform standardizes elsewhere.

Why not Workers-only (no GCP)?

• Cloudflare Workers can host the full relay (very cost-effective).
• Downside: platform tokens, CTS, and tenant registry live on GCP — cross-cloud latency, dual deploy, harder trace from ad event → agent QC.
• Compromise: Cloudflare edge (SSL, cache, WAF) → GCP Cloud Run origin — best performance/cost/ops balance.

Region

• Relay origin: europe-west1 (match GCP topology) unless tenant data residency requires otherwise.
• Cloudflare: automatic anycast edge (client-facing latency minimized globally).

Cost estimation

Planning bands only. Verify against Cloud Run, Cloud Load Balancing, Cloudflare plans, and Certificate Manager before build. Prices USD, order-of-magnitude, relay infra only (excludes Vertex, ads APIs, ERP).

Traffic assumptions

¹ Loader load + page/events + retries. Fan-out to Meta/TikTok/GA4 is outbound from Cloud Run (small payloads; egress cost negligible vs ingress).

Monthly infrastructure (USD)

Hybrid breakdown (Growth example, ~10M requests/mo):

All-GCP premium drivers: Global HTTPS LB (~$18+ base + LCU), Certificate Manager per hostname, no edge cache for k.js unless Cloud CDN added.

Marginal cost per tenant (steady state, hybrid)

Pass-through pricing to clients (optional SKU): media-tech fee €5–15 / site / month easily covers infra at Growth scale.

One-time engineering (build)

Opportunity cost vs v1 guide: v1 avoids this build; relay pays off at ~20+ active sites or when client IT friction dominates onboarding SLA.

Multi-tenant design notes

Phasing

See Roadmap — Phase 2+ optional.

Related documents

• ADR 0005: k.js relay micro-modules & CMP product
• Data & tracking
• GCP deployment topology
• Onboarding provisioning spec
• Platform access & API readiness
• Security & governance — GDPR / KVKK
• GA4 source of truth — Consent Mode v2 sign-off