First-Party Tag Relay (Kobi 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: Meta pixel, TikTok pixel, separate GTM publish per platform, client payment or platform billing.

Architecture options

A — Kobi 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.

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 Kobi Relay.

Consent management — required for Relay

Yes. If Kobi 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).

Three deployment modes (pick per tenant at onboarding)

Default recommendation: Mode 1 when CMP exists; Mode 2 as Relay SKU default for TR/EU SMB; document Mode 3 in implementation guide v2.

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:

Kobi maintains a compatibility matrix; unknown CMP → fallback Mode 2 or HITL onboarding step.

Phase F — Kobi 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: Kobi CMP adds negligible cost (static assets on same edge as k.js). No separate CMP SaaS fee unless Kobi later resells a third-party CMP.

Cloud provider recommendation

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

Why not AWS / Azure as primary?

• Rest of Kobi 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 Kobi 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

• 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