Tenant Reference — mycocoons

Tenant: mycocoons (F4 pilot tenant) Compiled: 2026-08-28 Status: reference only — non-secret data

Scope and non-authority

This file is a reference document, not runtime configuration. Nothing here is read by any service at runtime, and nothing here arms anything.

Tenant runtime configuration deliberately does not live in this repository (owner ruling 2026-08-23, .claude/rules/tenant-onboarding.md): tenant lane parameters are resolved per tenant from the onboarding vault through mizoki_contracts.tenant_lane_config, and credentials are written only through the tenant-scoped Secret Manager credential vault. The repo config/*.yaml files are shape-only templates; committing a tenant value into one is a governance defect. Do not create configs/tenants/, and do not convert any value below into a committed config.

Every identifier recorded here is a browser-side public identifier — values already served to any visitor of the storefront. No credential, token, secret, or private API key appears in this file, and none may be added to it.

Store

Tracking pixels

Extracted from the live storefront 2026-08-28. All are client-side tag identifiers embedded in the served page.

Also active on the storefront: GoAffPro, Smile.io, Weglot, Bily.

Platform rail mapping gaps

The identifiers above are storefront tags. They are not the identifiers the platform's server-side rails take. Each row below was verified against the tree on 2026-08-28; line references are to the state of main at that date.

1. Google Ads — wrong identifier class

AW-435589485 is a browser gtag conversion tag. The Enhanced Conversions rail takes a Google Ads API customer ID:

• services/measurement-rails/google_enhanced_conversions.py:148 — send_batch(..., customer_id: str, ...)
• line 159 builds customers/{customer_id}:uploadConversionAdjustments
• CONNECTOR_CATALOG's google_ads entry carries a required customer_id field, placeholder 1234567890 — 10 digits, no dashes (services/service-marketing-connectors/connector_credentials.py)

The two are different identifiers and are not interchangeable. The 10-digit customer ID must be read from the Google Ads UI; it cannot be derived from the AW- tag.

2. Meta CAPI — right shape, no production caller

Pixel 2190640941390833 is the correct shape for meta_capi.send_events(events, *, pixel_id=...) (services/measurement-rails/meta_capi.py:135), but that send path has no production caller:

• its only non-test in-repo caller is ncm_feed_wiring.send_meta_value_events (services/measurement-rails/ncm_feed_wiring.py:242)
• nothing in a serving path imports that function — main.py imports only the Klaviyo half of the module (main.py:92)
• services/measurement-rails/writeback.py:112 imports meta_capi but calls build_event only; its docstring is explicit — "constructed only; never sent here"

It is a flag-gated skeleton: WIRING_DEFAULT_ENABLED is the source literal False (ncm_feed_wiring.py:79, ast-asserted in tests), and a live send additionally requires require_rail plus an injected transport. Supplying the pixel ID wires nothing on its own.

3. Klaviyo — the site ID has no server-side slot

Td3DrR is the browser site ID. The W5 value feed authenticates with KLAVIYO_PRIVATE_API_KEY only (klaviyo_feed.py:47, API_KEY_ENV), and Klaviyo's Events API takes no company/site identifier server-side — neither company_id nor site_id appears anywhere in klaviyo_feed.py. The site ID is therefore not a value that gets wired in; it stays a storefront tag.

Correction to an earlier reading of this gap: it is not true that there is "no W5 config to wire it into". A W5 route exists and is live in source — POST /v1/rails/klaviyo-value-feed:send (services/measurement-rails/main.py:718), whose own docstring says it "gives ncm_feed_wiring.send_klaviyo_value_events its first real caller". The route is gated: a live send needs the KLAVIYO_FEED rail flag on, an operator-injected transport, and a non-empty credential env, each enforced by the rail itself. The gap is the missing credential and the absent identifier slot, not a missing route.

Related tree defect, recorded not fixed (out of lane): ncm_feed_wiring.py:46 still asserts "Nothing in any serving path imports this module", which main.py:92 contradicts. The tree wins; the docstring is stale.

4. CONNECTOR_CATALOG has no pixel field

CONNECTOR_CATALOG (services/service-marketing-connectors/connector_credentials.py:67) has no field of any kind for pixel IDs — the string pixel does not occur in the file. Unknown keys are rejected rather than ignored:

connector_credentials.py:333
    raise HTTPException(422, {"error": "unknown_fields", "fields": unknown})

So a pixel ID cannot be smuggled through the connector credential path; posting one returns 422. Persisting these identifiers needs either a catalog field added deliberately or a different onboarding surface.

Catalog summary

Figures below are extracted from the store, not platform-measured results; they carry no performance claim.

• 22 products (21 active, 1 draft)
• Primary product: Cocoon Knee Flex Pro at $49
• SKUs: RNJ00602309 (Medium), RNJ00602308 (Large)
• Multiple product entries per A/B test funnel
• Vendor: Yishun, ~52K inventory units
• ~14,900+ lifetime orders, AOV $55–70

Pending credentials

Canonical list: docs/tenants/TENANT_ONBOARDING_CHECKLIST.md. This section is no longer an ad hoc inventory — it records only this tenant's position against that checklist. Every value is collected through the authenticated onboarding UI and stored in the tenant-scoped Secret Manager vault; none may be requested in chat, and none may appear in this file, this directory, or any committed config (owner directive 2026-08-28, .claude/rules/tenant-onboarding.md §"Phase gate").

Collected is not armed: writing any of these does not start a pilot, register or alter a holdout, flip a rail flag, or widen autonomy (.claude/rules/tenant-onboarding.md).

Consent

All consent signals on the storefront currently default to GRANTED, and no CMP banner is present. A consent management platform is needed for GDPR/CCPA coverage.

This matters upstream of ingestion, not only legally: the consent gate precedes persistence as a schema-level hard gate (.claude/rules/03-canonical-architecture.md). A blanket default-granted storefront supplies no per-subject consent basis to carry into the canonical event envelope.