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

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.

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. What the rest of this document covers

The machinery that makes A to F 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/
• 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

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