October 1: script tags, Functions, the cart, the catalog agents read — Globalized Language ISO requirements

Companion checklist: Global compliance harness checklist: test-driven, AI-assisted — the tests to write before the code, for consent, privacy, payments, residency and the catalog (download the Markdown).

What Consent Mode v2 buys you globally

Google and Meta ads, lookalike audiences and Smart Bidding — managed by a server-side consent mandate.

A. The three-year conversion: from browser tags to server-side consent

Nine dated changes, from three rulebooks, between September 2023 and March 2027. Read top to bottom they are one conversion: measurement, audiences and checkout logic move out of the browser and behind a consent record the server keeps.

B. What each platform requires of you

Every channel that sells or retargets across borders — YouTube Shopping, Google Customer Match, Meta Custom Audiences, Shopify Audiences — ends at the same sentence: the advertiser confirms it has the consent the law requires. None of them collects that consent for you. A consent record kept on the server, itemised per market, is what lets one company run one media plan in the United States and abroad: reach where it is permitted, hold where it is not, and prove which was which.

C. What that buys

1. Reach US audiences from global markets, with consent. A buyer who granted release consent can be measured and retargeted on every platform above, whatever market they bought in.

2. Hold where consent is absent. The same order still counts — as an aggregate, with no identifier leaving the buyer's country (§8.3).

3. Prove which was which. Each platform makes you warrant the consent; the server-side record is the evidence behind that warranty.

4. Consent Mode v2 buys value-based growth. With ad_user_data and ad_personalization granted, one consented customer list — each customer carrying a predicted lifetime value (pLTV) — seeds three things: Google Smart Bidding on value (target ROAS, maximise conversion value), Google Lookalike segments in Demand Gen campaigns (seeded from Customer Match, at least 100 matched people), and Meta value-based Lookalike Audiences (seeded from a customer list with a value column). Without consent, none of the three may use that customer.

   Status here: the pLTV model is trained in BigQuery ML; the Google upload is built behind a flag for US audiences; the Meta upload is not built; Korean buyers stay out of every seed list until release consent exists (§8.3).

D. The rule: no session-level Consent Mode v2 log, no retargeting

A buyer enters a YouTube (Google) or Meta audience — or is sent as a purchase conversion with identifiers — only when a consent event for that session is on record: the session ID, the four Consent Mode v2 signals (ad_storage, analytics_storage, ad_user_data, ad_personalization), the time, and the version of the notice that was shown. Google and Meta ask the advertiser to warrant consent; this log is what turns the warranty into evidence for a specific purchase. A person's current consent answers "may we now?"; the session log answers "did they agree when they bought?".

What Google, Meta and the law add up to: a consent log kept in real time. No single rule says "real-time consent log" in those words. Read together, they leave no other way to comply:

Put plainly, and kindly: none of these platforms will keep this log for you, and every one of them — and every regulator behind them — will ask for it the day something goes wrong. A consent log written in the moment, per session, is the one document that ends that conversation early. Without it, the only answer to "show us they agreed" is a spreadsheet exported after the fact, and that is where the expensive part of a dispute begins.

The public record already shows the pattern. California's privacy regulator has fined two well-known brands for exactly this gap between the banner and the systems behind it:

The second case is the time-lapse risk in E made concrete: the banner said "opted out", and the systems behind it did not hear for forty days. Neither case needed a data breach.

Why January 2027 raises the stakes. California's Opt Me Out Act (AB 566, signed 8 October 2025) requires, from 1 January 2027, that browsers serving Californians include a built-in setting to send an opt-out preference signal. Today, few visitors send one, because it takes an extension or a privacy-focused browser. From that date it is a setting in the browser people already use — so the number of opt-outs arriving as a signal, on every page view, rises sharply. A store whose opt-outs travel by scheduled copy will be missing far more of them, far more often. A store that reads the signal at the edge and writes it to the consent log in the same request is unaffected by the volume.

E. Business-as-usual data handling vs API reinforcement with a global namespace

Most stores run on business-as-usual (BAU) data handling: one data state, shaped for one country (usually the US), kept separately inside each app. It works until the same customer, order or consent has to mean the same thing in a second market, a second language or a second ad platform.

API reinforcement moves the rules into the API that every system calls — the edge Worker and Xano's function stacks — so a record missing its market, language or consent is refused at the call, not discovered in a report. A global namespace is the shared set of keys that makes a record mean the same thing everywhere: market:<iso2>, BCP 47 language tags, ISO 4217 currencies, Shopify GIDs, $app: metafield namespaces, and one name per consent purpose.

The time-lapse risk. A withdrawal that takes hours to reach every system is a withdrawal ignored for hours. In that window a person who opted out is still emailed, still tracked, still in an uploaded audience — and that gap, repeated across millions of records, is where complaints, regulator inquiries and lawsuits come from. It is not a vendor defect; it is what any scheduled copy does. The fix is structural: the systems that act (send, track, upload) ask the consent record at the moment they act, instead of trusting a copy.

The namespace starts at the hostname. Stores that run one market per prefixed domain — uk.example.com, ca.example.com, www.example.com — often find every market showing the US consent banner. The usual cause: the consent platform's script and geolocation rules were set up once, for the parent domain, and each prefix inherits that US template instead of its own. The hostname is the first key in the global namespace, and it should resolve to a market before anything else loads:

• Cloudflare Rules match on the hostname (http.host) and the visitor's country, and set the market and consent defaults at the edge — a UK prefix gets UK defaults whether or not a script ever runs. See https://developers.cloudflare.com/rules/
• Each prefix that sends email needs its own SPF record. SPF does not inherit from the parent domain, so uk.example.com mail fails SPF unless that name publishes one; DMARC can fall back to the parent's policy, SPF cannot.
• The prefix declares the market; the visitor decides the law. A UK visitor on www is still owed UK consent. Route on both — hostname for market, visitor location and signals (such as Global Privacy Control) for the consent rules — and record both in the log.
• Google's reference for the hostname choice is Managing multi-regional and multilingual sites: country domain (example.de), subdomain (de.example.com), subdirectory (example.com/de/) or URL parameter (not recommended), each paired with hreflang. Google also warns not to adapt content by IP address. That fits the rule above: the prefix fixes what a page says, so crawlers see a stable page per market; the visitor's location changes only the consent defaults, never the content.
• The same top-level-down naming, behind the hostname. Cloudflare's Artifacts product uses namespaces as the top-level containers for repositories, split by environment (prod, staging, dev) or by tenant, with names that stay stable across Workers, API clients and Git. It names repositories, not URLs — but it is the same convention one layer down: the market prefix a visitor sees and the namespace that holds that market's configuration should be named once, top-level down, and never renamed in only one place. See https://developers.cloudflare.com/artifacts/concepts/namespaces/

Why the middleware keeps coming back. When a CRM is fed only through middleware, removing the middleware stops the CRM — so developers put it back, and the lag returns with it. Removing it is the wrong goal. Keep the middleware for what it does well, moving records into the CRM on a schedule, and take consent out of the copy: the CRM reads consent from the consent record through the API, and anything that acts on a person — a send, a tag, an upload — checks that record at the moment it acts. The CRM keeps running; the schedule no longer decides who may be contacted.

Status here: inbound Salesforce record events are received by the edge Worker, and Salesforce pulls erasures from an outbox this estate keeps, so no platform credential for Salesforce is held. Moving every consent read in a merchant's CRM onto the API is per-merchant work.

Klaviyo as the worked example. Klaviyo records, per profile, one marketing status per channel — SUBSCRIBED, UNSUBSCRIBED or NEVER_SUBSCRIBED — with the time and method of the last change, and logs subscribe and unsubscribe events. That answers one question well: may we email or text this person? It is not a per-purpose (ad_user_data, ad_personalization), per-market, per-session record, and it holds no release consent for moving data abroad — so on its own it cannot be the gate in D. Keep Klaviyo for messaging; let the API-reinforced consent record decide what may reach Google and Meta, and send Klaviyo the result.

Household panels and clean rooms: whose consent covers what. Household purchase panels (Circana, and NielsenIQ's Homescan) hold consent from their own panel households. That consent covers the panelists' data; it does not cover a store's customers. The moment a store sends its own customer or loyalty list to be matched, enriched or measured, the permission is the store's, and it goes through the same consent record as any Google or Meta upload.

Four things bite on household data. A household is personal information under the CCPA, whose definition covers information linked to "a particular consumer or household". Purchase segments can be health data: a segment built on over-the-counter or allergy purchases can fall under Washington's My Health My Data Act, where sharing needs consent and a sale needs the person's signed authorisation. The time-lapse risk becomes a file: a match file sent on a schedule keeps an opted-out person in the partner's copy, and the CCPA regulations require passing opt-outs on to the third parties who received the data in that gap — a suppression feed, not just a banner update. Korea is stricter: handing personal data to a panel or measurement partner is a provision to a third party under PIPA, and abroad it also needs the separate consent in §8.

How this estate applies it: sign-in claims, extras and the invitation to view, edit or share. The global namespace gives each of these its own key, so one never stands in for another:

• Sign-in (/auth/me) returns four separate things: the user, the claims (one consent flag per purpose, with its version), the extras (third-party identifiers — Adobe ECID, Nielsen ID, Circana household ID, segments) and the entitlement (what the account may use). Claims decide; extras are only ever keys that claims unlock. Xano's own auth/me works the same way: it checks the authentication token — an encrypted JWE — and returns the user, and a token can carry extras, such as a role, stored inside it (https://docs.xano.com/building-backend-features/user-authentication-and-user-data). Keep the two meanings of "extras" apart: token extras travel with every request, so they hold only small, non-identifying facts like a role; the extras table holds third-party identifiers, and a household ID never goes into a token.
• Clean room is its own consent purpose, not a feature someone buys. Every subject is excluded by default; a match job receives an explicit include or exclude for each person at each consent change, the latest decision wins, and the match list carries hashed references, never an email address. Withdrawing it removes the person from the next match.
• Withdrawing marketing consent clears the extras — the Adobe, Nielsen and Circana identifiers and the segments are emptied, and audience memberships are ended in the same step. Flipping a flag while the household ID stays in place would leave the retargeting running.
• An invitation grants a place, never a person. Teams invitations are single-use, expire after 14 days and store only a hash of the link. They carry role tags — admin, design, content edit, QA, security, agent; no tag means view only — so separation of duties is set at the invitation. Stacks separate who may view (visibility: public, group, named people, private) from who may edit or delete (protection: owner, admin, group). Shared assets name the reason for every decision (public, named people, invitation, purchase, group) in a ledger.
• Sharing a person's data asks the person's record, not the inviter's role. The share gate refuses if the subject opted out of sale or sharing or has not granted ad personalisation, then checks the actor: the subject themselves, a peer with a delegated grant, or an agent under a live mandate bound to that subject. Anything missing is a refusal.

Status here, stated plainly: the claims, extras, clean-room include/exclude, suppression on withdrawal, invitations and view/edit axes are built. Three gaps remain. The share gate is written and tested but not yet called by any route, so today sharing is governed by the invitation layer alone. Ad personalisation is derived from the marketing flag rather than held as a purpose of its own. And the session view releases the Nielsen and Circana identifiers when analytics alone is granted, where a measurement-match purpose should be required. Closing those three is the next step before any household match file leaves the estate.

Where this is proved: outside the closed Kubernetes and Red Hat pair. Xano runs on managed Kubernetes and Docker. Large companies often run their own Kubernetes too — on Red Hat OpenShift in an internal cloud or on-premises — but that side needs a subscription, a cluster and a platform team before the first test can run. The advantage of validating outside is timing: the data shape, the auth/me claims, the consent purposes (clean room included) and the invitation rules are built and proved by tests on public, synthetic or consented data, before anyone buys a cluster. What crosses into the closed side is the contract — schema, gate rules, harness tests, AI eval set and MCP tool definitions — not the data. The closed side runs the same contract (on OpenShift, or as Xano Standalone in the client's own cluster), Terraform adopts the pieces, keys are minted fresh, and the same tests must pass there. If one fails inside, the handover stops.

Circana, Nielsen and Adobe IDs live on the closed side, behind a protected endpoint. These are the identifiers that turn a customer into a household, a panel match or an Adobe profile, so they are the last thing that should sit in a shared layer. In the closed pair — an Azure estate, for example — the Circana household IDs, Nielsen IDs and Adobe IDs are held in one store reached only through an Azure private endpoint: a network interface with a private IP address in the company's own virtual network. Microsoft notes that a private endpoint does not by itself switch off public access, so public network access is disabled on the store as a separate step. Callers authenticate with a Microsoft Entra ID token issued to a service (client credentials), and the Cloudflare side reaches in only through Cloudflare Tunnel, an outbound connection from inside, so no inbound port is opened.

The endpoint answers questions, not lists: is this person included in the match (include or exclude, from the clean-room consent) or how many and how much (totals). It never returns the identifier itself. The prep layer carries hashed references in its place, and a withdrawal clears them on both sides — the prep layer's extras in the same step, the closed store through the suppression feed.

Status here: the prep-layer half is built (consent-gated clean-room include and exclude, hashed references, extras cleared on withdrawal). The Azure store, private endpoint and Tunnel are the client's closed side and are set up at handover; today, in the demo estate, those identifiers sit in the prep layer's extras table, released only with consent.

How OpenShift connects to off-prem Docker and Kubernetes — and the gap every SaaS-to-on-prem integration leaves. Four layers cross the boundary, and Red Hat has a documented answer for each:

Xano's managed service and Cloudflare are services, not clusters to join: OpenShift reaches them over HTTPS like any API. At handover, what moves inside is the images and the Git repository — and, if the work was done right, the contract.

The fifth layer is the one that is missing. SaaS-to-on-prem data integrations — scheduled syncs, middleware and EDI exchanges alike — move copies of records. The schema, the gate rules and the consent state that made those records valid stay behind on the SaaS side. Each side then keeps its own history, and every difference is found later, by hand, in a reconciliation report: an order that exists on one side only, a price that changed between runs, a withdrawal that the copy never heard about. Nothing in layers one to four fixes that, because they move software, not agreement.

What closes it is the same rule as the rest of this document: the contract crosses with the images and Git — schema, gate rules, harness tests, eval set — the same tests pass on both sides, and one ordered, in-region log records each change once, so both sides replay the same history instead of comparing two. Drift then shows up as a failing test at handover, not as a reconciliation meeting a month later.

F. Checklist for global Shopify stores: retire from the critical path, then adopt

The dates in A retire mechanisms, not companies. Every tool named below can stay in your stack; what has to go is the pattern it may be carrying. Run the check against each tool you use — the examples are tools commonly installed in each category, not a verdict on any of them.

Retire from the critical path

Naming convention, top-level down. Every lower level is derived from the one above it; no system invents its own name for a market ("korea", "asia") where an ISO code exists.

Adopt

G. Test-driven compliance with AI: the harness checklist

The last row of F — a test harness with compliance gating — is what keeps A to F true after the day they are written. This section says what that means in practice and gives the checklist.

Download the global compliance harness checklist (Markdown) →

TDD and unit testing are not the same thing. A unit test is a kind of test: it runs one function on its own, with everything around it faked. Test-driven development (TDD) is an order of work: write the test first, watch it fail (red), write the least code that makes it pass (green), then tidy the code with the test still passing (refactor). The two are independent. You can write unit tests after the code, which is not TDD; and you can do TDD with any kind of test — unit, integration, or a browser test that pays with a test card.

Why compliance needs TDD, not just tests. A legal rule written after the feature is tested against what the feature already does, so the test tends to agree with the code. Written first, the test states the rule — "no ad request before consent", "no Korean identifier to Google before overseas-transfer consent" — and the code has to meet it. Once in the gate, the rule is checked on every deploy, not once at launch.

Where the AI fits. An AI agent is good at the slow parts of TDD: turning a rule's text into a failing test, writing code until it passes, and running the suites. It must not be the judge of its own work. In this estate the agent drafts, a person reads every test that states a legal rule, and the gate refuses a release when a test fails, is skipped, or is quietly added to the known-failures list. The download button above was built this way: a test for the download route was written and failed before the route existed.

Paying in a test: Selenium and Playwright. Unit tests cannot show that a buyer can pay, or that no ad tag fired before they agreed to one — that takes a real browser on a real page. Both tools drive one. Neither should ever touch a live card: use a development store with Shopify's Bogus Gateway (card number 1 approves, 2 declines, 3 fails) or Stripe test mode (4242 4242 4242 4242 succeeds; 4000 0027 6000 3184 requires a 3-D Secure challenge).

The consent test is where Playwright is simplest, because it can list every request the page made:

// consent.spec.ts — Playwright. Written first; it fails until the stack loader defers tags.
import { test, expect } from "@playwright/test";

const AD_HOSTS = /google-analytics\.com|googletagmanager\.com|doubleclick\.net|facebook\.com\/tr/;

test("no advertising or analytics request before consent", async ({ page }) => {
  const early: string[] = [];
  page.on("request", (r) => { if (AD_HOSTS.test(r.url())) early.push(r.url()); });
  await page.goto("https://dev-store.example.com/");
  await page.waitForLoadState("networkidle");
  expect(early).toEqual([]);            // nothing fired while consent is denied
});

test("pays with the Bogus Gateway", async ({ page }) => {
  await page.goto("https://dev-store.example.com/products/sample");
  await page.getByRole("button", { name: /add to cart/i }).click();
  await page.goto("https://dev-store.example.com/checkout");
  // Card fields sit in the gateway's own iframes; selectors vary by checkout — read yours.
  await page.frameLocator("iframe[title*='Card number']").locator("input").fill("1");
  await page.frameLocator("iframe[title*='Expiration']").locator("input").fill("12 / 30");
  await page.frameLocator("iframe[title*='Security code']").locator("input").fill("123");
  await page.frameLocator("iframe[title*='Name on card']").locator("input").fill("Test Buyer");
  await page.getByRole("button", { name: /pay now/i }).click();
  await expect(page.getByText(/thank you/i)).toBeVisible();
});

The same payment in Selenium, where each iframe has to be entered and left explicitly:

# test_pay.py — Selenium 4, Python. Bogus Gateway on a development store only.
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

def fill_in_frame(driver, title_part, value):
    frame = WebDriverWait(driver, 15).until(EC.presence_of_element_located(
        (By.CSS_SELECTOR, f"iframe[title*='{title_part}']")))
    driver.switch_to.frame(frame)
    driver.find_element(By.CSS_SELECTOR, "input").send_keys(value)
    driver.switch_to.default_content()   # back out before the next frame

def test_pays_with_bogus_gateway():
    driver = webdriver.Chrome()
    try:
        driver.get("https://dev-store.example.com/products/sample")
        driver.find_element(By.XPATH, "//button[contains(., 'Add to cart')]").click()
        driver.get("https://dev-store.example.com/checkout")
        fill_in_frame(driver, "Card number", "1")
        fill_in_frame(driver, "Expiration", "12 / 30")
        fill_in_frame(driver, "Security code", "123")
        fill_in_frame(driver, "Name on card", "Test Buyer")
        driver.find_element(By.XPATH, "//button[contains(., 'Pay now')]").click()
        WebDriverWait(driver, 30).until(
            EC.presence_of_element_located((By.XPATH, "//*[contains(., 'Thank you')]")))
    finally:
        driver.quit()

Each payment test gets its failing twins — 2 must show a decline, 3 a gateway error — and the consent test gets one per market, since the rule differs by where the buyer is. The checklist lists them all: the gate itself, consent before measurement and before retargeting, where personal data may go, data subject requests, payments, Shopify after 1 October, the catalog, accessibility, and secrets.

H. What the rest of this document covers

The machinery that makes A to G true: where JavaScript is allowed to run after 1 October (§1–§4), what is reserved in cart and checkout (§5), the ISO standards a global catalog uses (§6), and — for Korea — the routes, the rules and the consent that must come before any retargeting (§8).

On 1 October 2026 a Shopify app can no longer create or update a script tag, on any API version. On 1 March 2027 the ones already installed stop loading. The replacement is not a different way to inject JavaScript — it is a rule about where each kind of code is allowed to run: layout in the theme, app code in an app embed, measurement in a web pixel, pricing logic in a Function, and product data in a catalog read by agents.

Who this is for: the merchant or business analyst who has to know what stops working and when; the developer who has to move the code; the compliance reviewer who has to know where data now flows. The question it answers: after 1 October, where does each piece of storefront JavaScript go, and what names and formats are reserved on the way?

Every date and limit below is quoted from Shopify's developer documentation or the UCP specification, linked in §9. Where a claim came from elsewhere and could not be confirmed there, it is marked unconfirmed.

0. Vocabulary

Several of these words mean two different things, and the deadline only applies to one of them.

1. The dates

What keeps working after 1 October: existing script tags keep running until 1 March 2027, and the scriptTags query and scriptTagDelete mutation keep working, so an app can audit and clean up what it installed.

What breaks that is easy to miss: any flow that creates or updates a script tag. That includes onboarding, a settings screen that re-registers a URL, and reinstalling an app on a store. The app does not fail on 1 March; it fails the next time someone installs it.

How to see a store's script tags without API access: view the page source of any storefront page and search for asyncLoad. Shopify renders active script tags as a list of URLs inside that function in content_for_header. No asyncLoad block means no script tags. (An observation method, not a documented contract: Shopify says not to parse content_for_header, because its contents may change.)

2. Where each kind of JavaScript goes now

The script tag was one mechanism for five different jobs. Each job now has its own place, with its own rules.

{% javascript %} in detail, from Shopify's theme documentation:

A claim to treat as unconfirmed: that the script_tag Liquid filter always emits type="text/javascript" and cannot add defer or type="module". Shopify's documentation does recommend hand-written <script src="{{ 'x.js' | asset_url }}" defer> (Theme Check, ParserBlockingJavaScript), which is the safe pattern either way.

3. What a Shopify Function may spend

Functions run inside cart and checkout, so Shopify enforces a hard budget. For carts of up to 200 line items:

Why the language matters: everything becomes WebAssembly. Shopify accepts a Function in any language that compiles to Wasm and meets its Wasm API: Rust, Zig or TinyGo compile directly; JavaScript is compiled by Javy, which packages a JavaScript engine into the module. The budget below is counted in Wasm instructions, so the engine inside a JavaScript Function spends part of the budget before your logic runs.

JavaScript or Rust. Functions can be written in JavaScript or TypeScript, but Shopify's documentation is explicit: JavaScript reaches the instruction limit sooner than a language that compiles directly to WebAssembly, and Shopify strongly recommends Rust. JavaScript is fine for a prototype; a Function that sees large carts should be written in Rust from the start, because a Function that runs out of instructions fails at checkout.

A Function with a backend: decide before checkout, read at checkout

A Function cannot call your backend while the buyer checks out. Network access (the fetch target) is limited to custom apps on Enterprise stores and has to be requested. So the work splits in two: the backend decides ahead of time and stores the decision on Shopify, and the Function reads that decision as part of its input.

Xano view — the function stack, top to bottom. In Xano's editor each step below is one card in the stack; in XanoScript it reads as follows (illustrative, generic names, shortened):

query "demo/discount-rules" verb=POST {
  input  { text token { sensitive = true }   text discount_id
           text[] vip_collection_ids?        text[] excluded_collection_ids? }
  stack {
    redis.ratelimit { key = "demo_discount_rules:" ~ $env.$remote_ip  max = 10  ttl = 60 }
    precondition (token matches)                 { error_type = "accessdenied" }   // 403
    precondition (discount_id is a discount gid) { error_type = "inputerror" }     // 400
    var $rules { vipCollectionIds, excludedCollectionIds }
    precondition (each list has at most 100 IDs) { error_type = "inputerror" }     // refuse here, not at checkout
    api.request { POST https://{shop}/admin/api/2026-07/graphql.json
                  metafieldsSet(ownerId: discount_id, namespace: "$app:discount-rules",
                                key: "config", type: "json", value: $rules|json_encode) }
  }
  response = { saved, metafield, userErrors, rules }   // never the admin token
  history = false                                      // the request is not logged
}

On the Shopify side, the Function declares where its variables come from, and uses them in its input query:

# shopify.extension.toml
[extensions.input.variables]
namespace = "$app:discount-rules"
key = "config"

query Input($excludedCollectionIds: [ID!], $vipCollectionIds: [ID!]) {
  cart {
    lines {
      id
      merchandise {
        ... on ProductVariant {
          product {
            inExcludedCollection: inAnyCollection(ids: $excludedCollectionIds)
            inVIPCollection: inAnyCollection(ids: $vipCollectionIds)
          }
        }
      }
    }
  }
}

Why this shape: the Function never searches, fetches or computes membership itself — Shopify answers inAnyCollection before the Function runs — so the instruction budget is spent only on applying the rule. The backend can take as long as it needs, and the checkout pays nothing for it. What it costs: the decision is only as fresh as the last write. A collection change reaches checkout when the backend writes the metafield again, not before.

4. Server-side data: what storefront JavaScript may assume

The pattern behind every change above is the same: the server decides, the browser reads. JavaScript that computed prices, decided eligibility or gathered data on its own is being moved to places the merchant and the visitor can see and control.

5. What is reserved in the cart and checkout

Reserved names are how Shopify separates what the buyer sees from what systems pass to each other. Using the wrong prefix either shows internal data to a customer or hides it from the code that needs it.

The rule that follows: anything a system needs and a buyer must not see goes in a double-underscore cart attribute. A single-underscore line item property is private only if every theme that renders it remembers to filter it.

6. The catalog agents read, and the ISO standards it uses

Shopify exposes products to AI agents through the Universal Commerce Protocol (UCP) Catalog capability: search_catalog and lookup_catalog, with the Global Catalog spanning all merchants and the Storefront Catalog scoped to one store. Both answer with UCP version 2026-08-25.

The naming trap between two Shopify surfaces:

A pipeline that copies one into the other without mapping sends PT_BR where a tag is expected, or zh-Hans where the enum has ZH_CN. Map explicitly, in one function, and test it.

Is the catalog replacing product CSV?

No — and the difference matters. The UCP Catalog is a read interface: agents search and look up products that already exist. Nothing is uploaded through it, and Shopify's Global Catalog infers some product fields from published product data rather than accepting a submission.

What does change for anyone moving off CSV: the fields agents read are the ones the product record holds — title, description, price, identifiers, availability — so a catalog that was "good enough in a spreadsheet" is now read literally by software. Missing GTINs, prices without a currency, and descriptions in the wrong language become wrong answers to a shopper.

6.1 Products, users, tags and categories: the dataset pipeline behind the funnels

The catalog is what agents read. The funnels are what the business measures: which topics, phrases and categories bring a person from a video or a search to a purchase. They share four datasets, and the language rule of §6 applies to every one of them: text is tagged with a BCP 47 language and routed by it, never blended across languages.

How the funnel is keyed — three signals, from exact to broad, each with its own job:

The Vertex step, and why it is optional. Where a business already runs Google Cloud, a Python job (or BigQuery SQL) can call Vertex AI through a BigQuery connection to embed or score text where the data already is, and write the result back as a column — the pattern in the estate's sentiment-funnel specification: score in BigQuery, not in the worker. What the job may read is fixed:

Status: the Python Vertex pipeline is a design, not built. The four datasets, the Vectorize indexes and the topic subjects exist; the Vertex embedding and scoring job does not. Topic subjects are defined by their keywords and phrases today, and nothing yet places content into them by meaning. Topic-driven assignment by embedding is the next step.

7. This estate's status

Measured on 29 September 2026.

What this does not claim: that every app installed on a merchant's store has migrated. Third-party apps own their own script tags; the asyncLoad check above is how a merchant finds them.

8. Korea: where the restricted APIs route, and the consent that gates retargeting

A US company selling into Korea meets the same October deadline, plus a set of services that do not work there or only work from a fixed address. None of this blocks selling; each row has a route.

YouTube to lead funnel · consent to e-commerce funnel

Search terms: Clean Energy · Korea · API · Audience

YouTube video (topic signal, no viewer data) → video page → lead form, with processing and cross-border consent → Kakao Pay deposit → order → retargeting only with release consent (§8.3).

Watch the Korea Clean Energy video, then try the Ondol Life lead form →

Example only: the video page and the lead form are demonstrations. Prices are illustrative, not a quote, and the 10% Kakao Pay deposit is a test payment — no money is charged. The page is also in Korean.

8.1 The map

8.2 TLS and login requirements

8.3 Automated checkout and global conversions: NICEPAY to Google, YouTube and Meta — reaching US audiences from global markets, with consent

The path a US company wants is simple to draw: a Korean buyer pays through NICEPAY, the order is confirmed server-side, and the conversion is sent to Google Ads (YouTube campaigns) and Meta so they can measure and retarget. The step that decides whether that is lawful is not in the payment flow. It is the buyer's consent to release their data abroad.

NICEPAY approval ──▶ signature + amount checked ──▶ Shopify order (system of record)
                                                          │
                                        ┌─ release consent on record? ─┐
                                        │ no                           │ yes
                                        ▼                              ▼
                          aggregate count and value only     conversion with identifiers
                          (no identifier leaves Korea)       to Google Ads / Meta, and
                                                             eligibility for retargeting

Why consent, specifically. Since 15 September 2023, PIPA Article 28-8 allows a transfer of personal information abroad on one of five grounds: separate consent, law or treaty, processing necessary to perform a contract with the person, a PIPC certification, or a PIPC adequacy decision. Sending a buyer's details to an ad platform so they can be retargeted is not needed to deliver their order, so for most US companies separate consent is the ground that applies. The consent has to tell the buyer what is transferred, to which country, when and how, to whom, for what purpose and for how long, and that they may refuse.

This is the feature a US company needs from its data layer: a release-data consent, itemised the way PIPA requires, recorded with evidence, and checked server-side before any conversion or audience upload — with "aggregate only" as the default when it is absent. A browser tag cannot enforce that: it fires before the server knows whether consent exists.

This estate's honest status:

PIPA points here are a map for a conversation with Korean counsel, not legal advice.

8.4 NICEPAY for Kakao Pay into Google channel automation: the consent permissions

The payment. NICEPAY offers Kakao Pay inside its own payment window — method values kakaopay, kakaopayCard and kakaopayMoney (Samsung Pay is samsungpayCard; each easy-pay method needs its own contract). The page opens the window; our server confirms with POST /v1/payments/{tid} and the amount, and checks NICEPAY's signature, hex(sha256(tid + amount + ediDate + SecretKey)), before anything is recorded. Kakao Pay can also be taken directly through Kakao Pay's own API; either way the result is the same confirmed, server-side order.

The automation. From that order, three things can be automated toward Google and Meta: reporting the conversion, adding the buyer to an audience, and targeting by topic. Each needs a different permission, and two different rulebooks apply at once — Google's and Meta's consent signals, and Korean law.

Two rulebooks, stated separately. Google defines ad_user_data as consent "for sending user data related to advertising to Google" and ad_personalization as consent "for personalized advertising", and enforces them for EEA traffic under its EU user consent policy. For a Korean buyer the obligation comes from PIPA, not from Google — but sending the two signals anyway puts the buyer's choice into every record Google receives, and the Data Manager API carries a consent object on each request for exactly that.

The order of operations that makes it lawful: payment confirmed → release consent looked up server-side → only then an upload, with the consent signals set from that record. A tag in the browser cannot follow this order: it fires on the thank-you page, before the server has checked anything.

8.5 Wallets and agent protocols: the APIs, and where each works

One naming rule across all of them. Google publishes its API design rules as API Improvement Proposals — resource names such as accounts/{account}/products/{product} (AIP-122), standard methods, paging and errors. The tools an agent calls here follow the same rules, so an agent built on ADK or UCP reads them the way it reads Google's own APIs. The rules name things; they do not grant anything — every tool still checks permission and consent itself.

8.6 One path, segmented by region: Shopify UCP → Google audience → NICEPAY

The same shopper journey runs in every market. What changes by region is the payment rail and what may be sent to Google — and one router, keyed by the buyer's ISO 3166-1 country, decides both.

                    Agent or shopper
                           │
        Shopify UCP catalog (search_catalog / lookup_catalog)
        address_country · language · currency  (ISO 3166-1 · BCP 47 · ISO 4217)
                           │
             market router (by ISO 3166-1 country)
          ┌────────────────┼──────────────────────┐
          US               KR                     KP · IR · SY
   Google Pay (live)   Kakao Pay (default)        refused: blocked markets
   Samsung Pay         Samsung Pay                never settle
   Web Checkout        through a Korean PG
                       (NICEPAY: kakaopay, samsungpayCard)
          │                │
          └──── Shopify order (system of record) ────┘
          │                │
   Google audience     Google audience held until release consent;
   (consent-gated)     topic and placement targeting only

A gap stated rather than hidden: the worker's slot for a Korean payment gateway is a placeholder named for another PG (KG Inicis) and reports itself unavailable. NICEPAY is built as Xano endpoints, but not yet connected to that slot. Until it is, Samsung Pay in Korea cannot settle through the worker; Kakao Pay can, through its own direct connection.

9. What it costs

10. What to do next

Ordered by exposure — the first item fails in two days.

1. Find every code path that creates or updates a script tag — install, onboarding, settings, reinstall — and replace it before 1 October 2026. Owner: app developer.
2. Audit each store's live script tags (scriptTags query, or asyncLoad in page source) and assign each URL to its replacement in §2. Owner: merchant, with each app vendor.
3. Move tracking scripts to web pixels that read consent before sending. Owner: marketing engineering; reviewed by compliance.
4. Move private system data to double-underscore cart attributes, and filter single-underscore line item properties in every theme that renders them. Owner: theme developer.
5. Write one mapping between BCP 47 language tags and the Admin LanguageCode enum, with tests, before any pipeline copies between them. Owner: integration developer.
6. Check product records for what agents will read: GTIN or MPN, currency on every price, description language. Owner: catalog owner.
7. For Korean buyers, hold every identifier until release consent exists: build the itemised PIPA 28-8 consent, record it with evidence, and gate conversion and audience uploads on it server-side; send aggregate counts only until then. Review what the store's custom conversion pixel sends first. Owner: data layer developer; reviewed by Korean counsel.
8. Call NICEPAY and Coupang from a fixed IP (Xano), with a TLS 1.2 client, and allowlist NICEPAY's webhook addresses. Owner: integration developer.
9. Require a session-level Consent Mode v2 record before any retargeting upload: a purchase's identifiers go to Google or Meta only when the consent event for that purchase's session is on record. Owner: data layer developer; reviewed by compliance.
10. Connect NICEPAY to the worker's Korean payment slot, replacing the KG Inicis placeholder, so Samsung Pay can settle in Korea alongside Kakao Pay. Owner: integration developer.
11. Remove what is left by 1 March 2027, when script tags stop loading. Owner: app developer.

Dictionary: AI and API terms

One line each, in the sense this document uses them. Terms defined at length in §0 are repeated briefly here so the list stands on its own.

Sources

• Shopify changelog, 24 Aug 2026: Script tags are deprecated and will stop running on March 1, 2027 — https://shopify.dev/changelog/posts/online-store-script-tags-deprecation

• Script tag deprecation guide and Order status timeline — https://shopify.dev/docs/apps/build/online-store/script-tag-deprecation

• Shopify Functions limitations and resource limits — https://shopify.dev/docs/api/functions

• JavaScript for Functions — https://shopify.dev/docs/apps/build/functions/programming-languages/javascript-for-functions

• Rust for Functions — https://shopify.dev/docs/apps/build/functions/programming-languages/rust-for-functions

• WebAssembly for Functions — https://shopify.dev/docs/apps/build/functions/programming-languages/webassembly-for-functions

• Network access for Functions — https://shopify.dev/docs/apps/build/functions/network-access

• Input query variables from metafields — https://shopify.dev/docs/apps/build/functions/input-queries/use-variables-input-queries

• JavaScript and stylesheet tags in themes — https://shopify.dev/docs/storefronts/themes/best-practices/javascript-and-stylesheet-tags

• content_for_header — https://shopify.dev/docs/api/liquid/objects/content_for_header

• Ajax Cart API, private properties and attributes — https://shopify.dev/docs/api/ajax/reference/cart

• POS cart API, private properties — https://shopify.dev/docs/api/pos-ui-extensions

• Reserved prefix protection for metafields and metaobjects, 19 Feb 2025 — https://shopify.dev/changelog/posts/reserved-prefix-protection-for-metafields-and-metaobjects

• checkout.liquid deprecation — https://shopify.dev/docs/storefronts/themes/architecture/layouts/checkout-liquid

• Web pixels and the Customer Privacy API — https://shopify.dev/docs/apps/build/marketing/pixels

• Shopify catalogs for agents — https://shopify.dev/docs/agents/catalog

• UCP Catalog specification (2026-04-08) — https://ucp.dev/2026-04-08/specification/catalog/

• Bulk operation imports — https://shopify.dev/docs/apps/build/apis/graphql-admin/bulk-operations/imports

• Google API design rules used on the merchant surface — https://google.aip.dev/general

• Migrate from Content API for Shopping to Merchant API (sunset 18 Aug 2026) — https://developers.google.com/merchant/api/guides/compatibility/overview

• NICEPAY developer manual, integration preparations (TLS 1.2, hosts, IPs, Basic auth) — https://github.com/nicepayments/nicepay-manual/blob/main/common/preparations.md

• PIPA 2023 amendment, overseas transfer grounds — Lexology, https://www.lexology.com/library/detail.aspx?g=4e246fbb-9f7a-48dc-9435-410a577d6ff8 ; Shin & Kim, https://www.shinkim.com/eng/media/newsletter/2048

• Items a Korean overseas-transfer notice must state — DLA Piper, Data Protection Laws of the World, https://www.dlapiperdataprotection.com/?t=transfer&c=KR

• YouTube Shopping affiliate program, overview and eligibility (14 regions) — YouTube Help, https://support.google.com/youtube/answer/13376398

• NICEPAY payment window (server approval), methods and signatures — https://github.com/nicepayments/nicepay-manual/blob/main/api/payment-window-server.md

• Google consent mode (ad_user_data, ad_personalization) — https://developers.google.com/tag-platform/security/guides/consent

• Google: updates to consent mode for EEA traffic (March 2024) — https://support.google.com/google-ads/answer/13695607

• GDPR Article 7, conditions for consent — https://gdpr-info.eu/art-7-gdpr/

• California: CCPA and Global Privacy Control (opt-out within 15 business days) — https://oag.ca.gov/privacy/ccpa/gpc ; California Privacy Protection Agency FAQ — https://cppa.ca.gov/faq.html

• California Privacy Protection Agency: Honda settles over privacy violations (12 March 2025) — https://cppa.ca.gov/announcements/2025/20250312.html

• California Privacy Protection Agency: Todd Snyder ordered to pay fine (6 May 2025) — https://cppa.ca.gov/announcements/2025/20250506.html

• California Opt Me Out Act (AB 566), browser opt-out preference signal from 1 January 2027 — https://privacy.ca.gov/2026/01/californias-opt-me-out-act-your-privacy-just-got-easier

• Google Search Central: managing multi-regional and multilingual sites — https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites ; localized versions (hreflang) — https://developers.google.com/search/docs/specialty/international/localized-versions

• Cloudflare Rules — https://developers.cloudflare.com/rules/

• Xano: User Auth & Data (auth/me, JWE tokens, extras) — https://docs.xano.com/building-backend-features/user-authentication-and-user-data

• Red Hat OpenShift — https://www.redhat.com/en/technologies/cloud-computing/openshift

• Azure Private Link: what is a private endpoint — https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-overview

• Microsoft Entra ID: OAuth 2.0 client credentials flow — https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-client-creds-grant-flow

• Cloudflare Tunnel — https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/

• Red Hat Developer: adapting Docker and Kubernetes containers to run on OpenShift (arbitrary user IDs) — https://developers.redhat.com/blog/2020/10/26/adapting-docker-and-kubernetes-containers-to-run-on-red-hat-openshift-container-platform

• Red Hat OpenShift GitOps: setting up an Argo CD instance — https://docs.redhat.com/en/documentation/red_hat_openshift_gitops/1.16/html-single/argo_cd_instance/index

• Red Hat Advanced Cluster Management datasheet (EKS, AKS, GKE and conformant Kubernetes) — https://www.redhat.com/en/resources/advanced-cluster-management-kubernetes-datasheet

• Red Hat Service Interconnect (Skupper) — https://docs.redhat.com/en/documentation/red_hat_service_interconnect/2.1/html/using_service_interconnect/skupper-overview

• California Civil Code §1798.140 (CCPA definitions, "consumer or household") — https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=CIV&sectionNum=1798.140

• CCPA regulations §7026(f)(2): notify third parties who received the data before the opt-out was honoured — https://www.law.cornell.edu/regulations/california/11-CCR-7026

• Washington My Health My Data Act, RCW 19.373 — https://app.leg.wa.gov/RCW/default.aspx?cite=19.373

• Cloudflare Artifacts: namespaces — https://developers.cloudflare.com/artifacts/concepts/namespaces/

• SPF (RFC 7208) — https://www.rfc-editor.org/rfc/rfc7208

• Google Ads Developer Blog: changes to Customer Match support in the Google Ads API (April 2026) — https://ads-developers.googleblog.com/2026/03/changes-to-customer-match-support-in.html

• Google Data Manager API — https://developers.google.com/data-manager

• Meta Conversions API — https://developers.facebook.com/docs/marketing-api/conversions-api

• Meta Customer List Custom Audiences Terms — https://www.facebook.com/legal/terms/customaudience

• Klaviyo: understanding consent in profiles — https://help.klaviyo.com/hc/en-us/articles/360037101072

• Klaviyo: collect email and SMS consent via API — https://developers.klaviyo.com/en/docs/collect_email_and_sms_consent_via_api

• Google Customer Match policy — https://support.google.com/adspolicy/answer/6299717

• Google Lookalike segments (Demand Gen) — https://support.google.com/google-ads/answer/13541369

• Meta value-based Lookalike Audiences — https://www.facebook.com/business/help/917879191754763

• Shopify Audiences setup and eligibility — https://help.shopify.com/en/manual/promoting-marketing/shopify-audiences/setting-up-shopify-audiences

• Kakao Pay developers — https://developers.kakaopay.com/

• Samsung Pay developers — https://developer.samsung.com/pay

• Google Pay API — https://developers.google.com/pay/api

• Google Wallet API — https://developers.google.com/wallet

• Universal Commerce Protocol — https://ucp.dev/

• Agent Development Kit — https://google.github.io/adk-docs/

• AIP-122 resource names — https://google.aip.dev/122

• Playwright: network events and frames — https://playwright.dev/docs/network ; https://playwright.dev/docs/api/class-framelocator

• Selenium: working with iframes, waits — https://www.selenium.dev/documentation/webdriver/interactions/frames/ ; https://www.selenium.dev/documentation/webdriver/waits/

• Shopify Bogus Gateway (test card numbers 1, 2, 3) — https://help.shopify.com/en/manual/checkout-settings/test-orders

• Stripe test cards, including 3-D Secure — https://docs.stripe.com/testing

• California CCPA regulations §7025, opt-out preference signals — https://cppa.ca.gov/regulations/

• European Accessibility Act, applicable from 28 June 2025 — https://eur-lex.europa.eu/eli/dir/2019/882/oj

Not legal advice and not a certification. Dates and limits are Shopify's and may change; check the linked pages before acting.