Design for Secure Revenue Projection

For: marketing and growth leads, analytics and data engineers, designers who build the consent and account surfaces, and the compliance reviewer who signs off what leaves the store. Genre: design specification.

A revenue signal is only as trustworthy as the least-checked hop it passed through. Design the checks as a component, with states and tests, the same way you design a button.

Vocabulary

The same words are used loosely in marketing, engineering and compliance. Here they mean one thing each:

The question this answers

Every store already projects revenue. The Google channel sends order values. A Klaviyo flow sends spend. A pLTV model sends predicted values. The question is not whether to do it, but who can prove, afterwards, that each signal was allowed to leave, and was the signal it claimed to be.

Most stacks answer with a review: a privacy assessment before launch, a penetration test once a year. A review checks the design once. Revenue signals leave every few seconds, through plugins that change monthly. The answer that holds up is a component that runs on every signal.

The components of a revenue projection

A projection is built from six components. Five are familiar. The sixth, security, is usually left out of the design and added as a review, which is the gap this document closes.

Identity, consent, value and purpose describe the signal. The adapter shapes it. Security is the only component that checks the other five actually held.

The security component

Contract

The component takes one signal and returns one decision:

input:   signal (value, pseudonymous ID, destination, purpose)
         + the consent state for that ID, read now, not cached from earlier
         + the sender's proof (a webhook signature, a service key)
output:  send | hold | refuse
         + reason
         + a record: what, to where, under which consent and purpose, when

It runs at every hop, not once at the edge. A check that only runs at the edge is bypassed by the first internal job that calls a channel directly.

States

The rule across all four: every failure fails toward less exposure. A gate that can't reach the consent record holds; it doesn't send.

Checks at each hop

Failure modes, as they look from outside

Each of these looks exactly like a working system until someone checks the record:

• A 200 that sent the wrong thing. The audience upload succeeds, but every member was stamped as consented because the batch was. The fix is a decision per person, recorded per person.
• A gate that opens late. Consent is checked after the upload is queued. From the dashboard, a late gate and a working gate look the same.
• An erasure that erased the original. The redact webhook returns 200 and deletes the store's copy. The Customer Match list and the pLTV score still hold the person.
• A fork in the record. Two writers append to the same ledger at once and both succeed, leaving two histories. Only a constraint on the previous hash makes the second write fail.
• A reporting address no one receives. The CAA reporting record exists, but its value starts with a space, so a strict certificate authority ignores it.

The two shapes the component checks

A security component can only check what it can read. Two shapes carry nearly every revenue signal: the product shape Google Merchant reads, and the customer event shape on the user tags bus. Both are fixed shapes, not free-form payloads, which is what lets the component, and an AI caller, rely on them.

The Google Merchant data layer shape

A product's price, availability and identifiers are revenue signals too: they decide what an ad or an AI shopping agent offers, and at what price. CRM Sync composes them in the Merchant API products_v1 shape, from one composer that feeds three surfaces: the public catalog at /merchant/products, three read-only Merchant tools on the MCP endpoint (merchant_get_product_by_name, merchant_list_products, merchant_list_aggregate_product_statuses), and a JSON block inside each product page. One composer means the three can't disagree.

One product, as served today:

{
  "name": "accounts/example.myshopify.com/products/en~US~<offerId>",
  "offerId": "<offerId>",
  "contentLanguage": "en",
  "feedLabel": "US",
  "productAttributes": {
    "title": "…", "description": "…", "link": "https://…", "imageLink": "https://…",
    "price": { "amountMicros": "129000000", "currencyCode": "USD" },
    "availability": "IN_STOCK", "condition": "NEW", "brand": "…",
    "identifierExists": false,
    "productTypes": ["…"],
    "shipping": [{ "country": "US" }],
    "shoppingAdsExcludedCountries": ["KP", "IR", "SY"]
  },
  "productStatus": { "itemLevelIssues": [
    { "code": "missing_identifier", "severity": "warning", "attribute": "gtins",
      "description": "Neither GTIN nor MPN present" } ] }
}

The walk from a flat product CSV to this shape, including why a missing Handle makes the same file read as 4 products or 169, is in From product.csv to Consented Conversions.

The user tags event bus

The customer side moves as events, not as copies of the customer record. Three tables carry it:

Seven domains write to the bus today: tag, consent, order, return, agentic, omnibus_discount and audience. An order event carries a conversion record in its payload, built for revenue projection rather than as a log line:

What the bus doesn't do yet. It is an event log, not yet an evidence chain:

• Writes are best-effort. A failed write is logged and the caller carries on, so an event can be missed without anyone being told. An outbox with retries would close it.
• Rows aren't chained or signed. Consent and erasure events are also written to the hash-chained, Ed25519-signed ledger; the bus rows themselves are not.
• The idempotency check reads, then writes. A unique index on the key is what actually stops a duplicate when two deliveries race.

Setting up an AI caller against both shapes

An AI agent, a chat assistant or an automated job reads these shapes to decide what to offer and what a customer has agreed to. The security component treats it like any other caller:

What is built, and how it is tested

The component is partly built. Each part is pinned by a test in the CRM Sync test harness: green tests guard what is built, and red tests fail on purpose until a gap is built.

The vendor-by-vendor detail behind the red rows is in The plugin in the middle, and which channel data may feed conversions, audiences, pLTV or model training is in Google audiences and conversions with Vertex AI, and where LoRA fits. The CAA steps, and a script that tests a domain red then green, are in CAA records.

Designing the visible part

Most of the component is invisible. Three parts reach a screen, and they are designed like any other component, with states:

The account and dashboard states come straight from the component's records, so the screen can't disagree with what was sent.

What it costs

• Fewer signals reach the channel. Holding until consent is known, and refusing on purpose, means smaller audiences and fewer conversion values than a stack that sends everything. Bidding learns from less data. That is the trade, and it should be stated in the plan, not discovered.
• Latency. A per-person gate adds a lookup before each send, and a batch is gated member by member. It is never free.
• One more system to own. The identity spine, the ledger and the gate run in Xano and Cloudflare. If those stop, projection stops, by design. That is a dependency the team takes on.
• Vendor coverage lags. Each new channel needs an adapter, an erasure call and a test before it is trusted. Until then it is a red row.
• The tests prove the code, not the vendor. A green erasure test proves the call is made; it doesn't prove the vendor deleted anything. Confirmations still have to be recorded and checked.

What to do next

1. List every revenue signal that leaves the store today, with the channel, the plugin that carries it, and the purpose of the data. Most teams find signals no one owns.
2. Write the security component's checks as tests before changing anything. Each check you can't pass yet is a red test, and the list of red tests is the plan.
3. Put the gate in front of the highest-volume signal first, usually the audience upload or the conversion value, and make it decide per person.
4. Move identity and consent to a record you own, so the gate reads the current choice, not the plugin's copy.
5. Add the visible states to the banner, the account page and the dashboard from the same records.
6. Turn one red row green at a time, and add each new channel with its adapter, its erasure call and its test together.

Resources and downloads

This document:

Companion brief: AI Security: Challenges, Benefits, and Tools (24 October 2026, 5 pages). It pairs five AI security risks (memory-unsafe native stacks, prompt injection, model supply chain, data leakage, over-privileged agents) with the defence each one gets from AI, shows a reference architecture for a secure AI data layer, and lists open-source and commercial tools and the frameworks auditors use (OWASP Top 10 for LLM Applications, MITRE ATLAS, NIST AI RMF, Google SAIF).

• Download the brief (PDF, 223 KB)

The brief's architecture is the target design. Its Rust Worker trust boundary corresponds to the Rust shape gate, which is a red row in What is built, and how it is tested: read the brief for where the design is going, and this document for what holds today.

Related sections:

• The plugin in the middle: where data ownership breaks between Shopify, CRM, service, fraud, consent and Google
• Google audiences and conversions with Vertex AI, and where LoRA fits: which channel data may feed conversions, audiences, pLTV or model training
• CAA records: naming the CAs that may issue for a domain, and a red-then-green test script
• From product.csv to Consented Conversions: the walk from a flat catalog file to the Merchant shape