These Terms apply when a merchant installs Arbling's storefront script on its own online store. They sit beside the Arbling Terms of Service (arbling.com/terms); where the two differ about storefront data, these Terms govern. The Journey Attribution Data Processing Addendum (the "Addendum") is a schedule to these Terms.
1. Parties, roles and acceptance
1.1 The parties. These Terms are between:
- Arbling Inc., a corporation under the Business Corporations Act (Ontario), Ontario Corporation No. 1001378754, registered office 325 Front Street West, Suite 300, Toronto, Ontario M5V 2Y1, Canada ("Arbling"); and
- the merchant that installs Arbling's storefront script (the "Storefront Script") on its own online store and accepts these Terms (the "Merchant").
1.2 Roles. "Storefront Data" is the data the Storefront Script collects from the Merchant's store, and from the Merchant's platform about orders linked to it.
- For Storefront Data, the Merchant is the controller, and Arbling is its processor. Under Canadian and United States privacy laws, Arbling is its service provider.
- Arbling processes Storefront Data only on the Merchant's instructions in these Terms and the Addendum, unless a law requires otherwise.
- Arbling tells the Merchant if it believes an instruction breaks a data-protection law.
1.3 Acceptance. The Merchant accepts these Terms inside Arbling with one click. Until it does, Arbling issues no site key for its store, and the Storefront Script collects nothing.
- What Arbling records: which Arbling account accepted, which version, who clicked and when.
- What Arbling does not record: the clicking person's IP address and browser.
- How long it keeps the record: while it holds Storefront Data for the Merchant, and afterwards for as long as it may need to show what was agreed.
1.4 The current version of these Terms is a server setting. Clause 7 says what happens when it changes.
2. What the Storefront Script collects
2.1 Counting, with no identifier. Once these Terms have been accepted, the Storefront Script counts visits to the Merchant's store.
- What a counted visit carries, and nothing else:
- the public part of the page's path, never its query string or any part that looks like a token;
- the host name of the referring site;
- whether the visit came from an AI assistant;
- which kind of AI agent or crawler made the request, if any;
- the product handle of a product page;
- for an order, lead, sign-up or booking that the Merchant marks on its page: its kind, plus the reference and value the Merchant's marker supplies.
- What counting does not use: it sets no cookie, reads no browser storage and stores no identifier.
- Telling one visit from many:
- Arbling's server combines the visitor's IP address and browser identification string, inside the request, into a one-way code under a random key that exists for one day (UTC).
- The code points to a random visit number for that day only.
- The IP address and the browser string are not stored.
- The key and the code are deleted at midnight UTC, so no visit is linked across days.
- What counting does not depend on: the shopper's consent signal. The Merchant can switch counting off (clause 6).
2.2 Journey attribution, with consent. The Storefront Script also records the pseudonymous visit trail described in the Addendum ("Journey Data"). If the shopper orders, it links the order to that trail. It does so only where clause 2.3 allows.
2.3 The consent signal.
- Where the signal comes from: the store's consent signal is read in this order:
- Shopify Customer Privacy;
- the IAB Transparency and Consent Framework;
- Google Consent Mode;
- Arbling's own consent adapter.
On WordPress, the WordPress Consent API is read first.
- A grant allows journey attribution.
- A refusal, a withdrawal or a Global Privacy Control signal stops it, and deletes the visit codes held in the browser.
- With no signal:
- Journey attribution runs only for visitors in Canada (including Quebec) and the United States, where the Merchant's privacy notice describes it and offers an opt-out (clause 4.1).
- Without a grant, it never runs for visitors in the European Union, the European Economic Area, the United Kingdom or Switzerland.
- AI agents and crawlers never enter journey attribution.
2.4 Never collected. Arbling does not collect, through the Storefront Script:
- names, email addresses, phone numbers or postal addresses;
- payment or card details;
- special-category data.
If the Merchant's platform sends such fields with an order, Arbling does not keep them.
3. Purposes
3.1 Journey Data: only the three purposes in the Addendum (clause 2.3): attribution, reporting to the Merchant, and usage billing where the Merchant's agreement with Arbling sets a usage fee.
3.2 Counting data: only to:
- (a) show the Merchant its own visits, AI traffic and conversions in its Arbling dashboard;
- (b) count the conversions on which the Merchant's agreement sets a usage fee, if it sets one;
- (c) keep the service secure, including rate limits and abuse prevention;
- (d) measure, with random hold-out groups, the effect of features the Merchant switches on.
3.3 What Arbling does not do with Storefront Data:
- sell or share it;
- use it for advertising or profiling;
- train third-party AI models on it;
- combine it with another merchant's data, or with data about the same people from other sources.
Arbling keeps Storefront Data separate for each Merchant.
4. What the Merchant commits to
4.1 Its privacy notice. The Merchant's privacy notice tells its visitors three things:
- that the store uses Arbling Inc. (Canada) as a processor to count visits and, where clause 2.3 allows, to attribute orders;
- how to opt out;
- that a Global Privacy Control signal is honoured.
The Merchant confirms this when it accepts these Terms. Arbling provides wording the Merchant may paste: the storefront disclosure template.
4.2 Consent. Stores that serve visitors in the European Union, the European Economic Area, the United Kingdom or Switzerland pass their visitors' choice to the Storefront Script through one of the sources in clause 2.3. The region commitment in the Terms of Service ("Storefront measurement") applies as written.
4.3 The conversion marker. The reference and value the Merchant passes contain no name, email address, phone number, postal address or payment detail.
4.4 No special-category data. The Merchant does not cause the Storefront Script to send Arbling special-category data.
4.5 Requests.
- Where they go: the Merchant forwards to hi@arbling.com any data-subject request it receives about Storefront Data, with the handle needed to find the records (for example, an order id).
- Counting data holds no identifier, so it holds nothing that can be found for one person.
4.6 Transfers. The Merchant, as controller, is responsible for its own transfer mechanism to Arbling where its visitors are outside the scope of Canada's adequacy decision (Addendum 8.2(c)).
5. What Arbling commits to
5.1 Confidentiality and access: as in Addendum 5.2.
5.2 Security: the measures in Addendum 5.3, for all Storefront Data.
5.3 Sub-processors:
- They are the ones in Addendum Annex C, for all Storefront Data.
- Arbling gives at least 30 days' notice of a new one.
- The Merchant may object, and may end the processing if the objection is not resolved (Addendum 5.4 and 8.3).
5.4 Breach: Arbling notifies the Merchant without undue delay, and in any case no later than 72 hours after becoming aware of a personal-data breach affecting Storefront Data (Addendum 5.6).
5.5 Assistance:
- with data-subject requests, as in Addendum clause 7;
- with the Merchant's obligations on security, breach notification, data-protection impact assessments and prior consultation, by giving the information Arbling has.
5.6 Records and audits: Arbling gives the Merchant the information reasonably needed to show that this processing follows these Terms, and cooperates with reasonable audits (Addendum 5.8).
5.7 Service-provider terms. Arbling:
- does not retain, use or disclose Storefront Data outside its direct business relationship with the Merchant, or for any purpose other than those in clause 3;
- gives Storefront Data the level of protection the privacy laws applying to the Merchant require;
- tells the Merchant if it can no longer meet these Terms;
- allows the Merchant to take reasonable steps to stop and remedy any use of Storefront Data that these Terms do not allow.
5.8 Location and transfers: as in Addendum 8.2. Arbling is in Canada, and Storefront Data is processed and stored in the United States by the sub-processors in Annex C.
6. Switching off and leaving
6.1 Switching off.
- The Merchant's control: the Merchant can switch the Storefront Script off in Arbling at any time with one control. It takes effect at once and asks for nothing else.
- Arbling's own switches: Arbling also holds a switch for each Merchant and one global switch.
6.2 Removing the Storefront Script or closing the Arbling account stops collection at once.
- Stored data:
- It runs out under the retention periods in the Addendum (Annex B) and in Arbling's Privacy Policy ("Data retention & deletion"), or is erased earlier on request.
- Counted visits are kept 180 days from the visit. That is a floor Arbling can raise, not a deletion date.
- For a Shopify store: Shopify's
shop/redact, about 48 hours after uninstall, erases its Journey Data (Addendum 7.3).
7. New versions
7.1 Publishing a new version. Arbling may publish a new version of these Terms, for example for a new sub-processor or a new kind of collection. The Merchant is asked to accept it the next time it opens its Arbling dashboard.
7.2 Until the Merchant accepts the new version:
- counting continues under the version it accepted;
- journey attribution stops (Addendum 9.3);
- Arbling issues no new site key.
The Merchant may switch off instead (clause 6).
8. Duration, fees and the rest
8.1 Duration: these Terms last while the Storefront Script is installed or Arbling holds Storefront Data for the Merchant.
8.2 Fees: these Terms set no fee. Any usage fee is in the Merchant's subscription agreement with Arbling.
8.3 Liability: as in the Terms of Service. Nothing in these Terms limits a liability that the law does not allow to be limited.
8.4 Governing law: these Terms are governed by the laws of the Province of Ontario and the federal laws of Canada applicable there, and the courts in Toronto, Ontario, have jurisdiction.
8.5 Order of precedence:
- for Journey Data: the Addendum, then these Terms, then the Terms of Service;
- for counting data: these Terms, then the Terms of Service.
8.6 Contact: hi@arbling.com.
Journey Attribution Data Processing Addendum
Version 2026-10-06, a schedule to the Arbling Storefront Privacy Terms
1. Parties and role
1.1 This Journey Attribution Data Processing Addendum (the "Addendum") is a schedule to the Arbling Storefront Privacy Terms (the "Terms") between Arbling Inc. and the Merchant.
1.2 Arbling Inc., a corporation under the Business Corporations Act (Ontario), Ontario Corporation No. 1001378754, registered office 325 Front Street West, Suite 300, Toronto, Ontario M5V 2Y1, Canada ("Arbling"), is the processor.
1.3 The merchant that installs Arbling's storefront script on its own online store and accepts the Terms (the "Merchant") is the controller.
1.4 Data-subject requests routed to Arbling go to hi@arbling.com, the address published in Arbling's Privacy Policy (arbling.com/privacy). No other mailbox is used.
2. Subject matter, nature, purpose and duration
2.1 Subject matter. "Journey attribution": when a shopper on the Merchant's storefront interacts with Arbling's storefront script (the "Storefront Script", also called the ATI beacon or Arbling widget), Arbling records a small, pseudonymous visit trail (the "Journey Data") and, if the shopper later orders, links the order to that trail so the Merchant can see which orders followed an AI-assisted visit.
2.2 Nature. This processing runs on the Merchant's instructions, for the Merchant.
2.3 Purpose. Three purposes only: (a) Attribution: recording the visit trail and linking it to a later order; (b) Merchant reporting: showing the Merchant its own journeys and funnel in its dashboard; (c) Usage billing: where the Merchant's agreement with Arbling (the "Agreement") sets a usage fee on attributed orders, the attributed order is the fee basis in the Agreement.
2.4 Arbling does not sell Journey Data, does not train third-party AI models on it, and does not run third-party advertising trackers.
2.5 Duration. Processing continues while the Merchant's Terms acceptance is current and the Storefront Script is active. Switching off or withdrawing under clause 9 stops new processing at once; records already held run out under the Annex B retention register, or are erased earlier under clause 7 (data-subject request) or clause 7.3 (uninstall).
3. Categories of data subjects and personal data
3.1 Data subjects. Storefront visitors and shoppers who interact with the Storefront Script on the Merchant's online store, including those who go on to complete an order.
3.2 Categories of Journey Data are described in Annex A. Arbling does not process names, email addresses, postal addresses, payment details or card data under this activity. If the Merchant's platform sends such fields in an order webhook, Arbling does not retain them.
3.3 Continuity cookie. Arbling's server sets one first-party cookie, __Host-arb_w2_v1, on the Merchant's storefront:
(a) Set only after the consent signal grants the "analytics" and "attribution" purposes in clause 4.2. No consent, no cookie. A Global Privacy Control (GPC) signal is a refusal.
(b) Value: an opaque, server-generated nonce. Arbling stores only a keyed hash of it, never the value.
(c) Lifetime: 24 hours maximum, absolute, never renewed (a 5-minute provisional state applies before activation); deleted earlier on consent withdrawal or refusal, Merchant configuration change or disablement, erasure, or uninstall.
(d) Attributes: Path=/; Max-Age=86400; Secure; HttpOnly; SameSite=None; Partitioned, scoped to that storefront only. No browser local storage is used.
4. Merchant instructions and Merchant obligations
4.1 The Merchant instructs Arbling to process Journey Data as set out in this Addendum. Arbling acts only on those instructions (clause 5.1).
4.2 Consent. The Merchant obtains and maintains the consent, or other signal, permitting this processing; Arbling does not obtain consent itself. The Merchant configures the signal source: (a) the Shopify Customer Privacy API, or (b) Merchant attestation that its own consent mechanism covers the analytics and attribution purposes.
4.3 Signal rule. Arbling's configuration rule, recorded in its privacy position, is: in the EU and UK only an affirmative consent grant is accepted as a sufficient signal; in Canada, Quebec and the United States Merchant attestation is accepted as sufficient, provided refusals and GPC signals always suppress processing and are honoured. Absent any signal, processing does not run.
4.4 The Merchant's consent warranty complements Arbling's code-level consent gate in clause 3.3(a); it does not replace it.
4.5 The Merchant publishes the storefront disclosure describing this processing to its shoppers.
4.6 The Merchant forwards to Arbling (hi@arbling.com) any data-subject request it receives about Journey Data, with the handle needed to locate the records (clause 7.4).
4.7 The Merchant does not cause the Storefront Script to send Arbling special-category personal data, or any category listed in clause 3.2 as not processed.
5. Arbling obligations
5.1 Arbling processes Journey Data only on the Merchant's documented instructions in this Addendum, unless a law requires otherwise.
5.2 Arbling keeps Journey Data confidential and limits access to personnel who need it to operate the service. Arbling has two officers (the Chief Executive Officer and the Chief Technology Officer) and no other staff; production access is held through individual named accounts only, and no third party has standing access. Arbling's hosting workspace at Railway is a single-owner workspace (measured 2026-09-16: one account). Database console access at MongoDB Atlas is limited to the two officers (confirmed by the founder 2026-09-16: two named console accounts, the Chief Executive Officer and the Chief Technology Officer, and no other user); multi-factor authentication is enabled on both accounts (confirmed by the founder 2026-09-16). Application access to the database uses one dedicated database user whose credential is held only in the hosting environment's secret store.
5.3 Security measures: (a) identifiers are HMAC-keyed with three separate, versioned secret keyrings (lookup, visitor, handle) held in the hosting environment, never in code; raw session ids and raw cookie values are never stored or logged; (b) tenant isolation: every record is scoped to the Merchant's tenant, with no cross-merchant join key in journey code (tests guard this); (c) transport runs over HTTPS, and the cookie is Secure, HttpOnly and Partitioned; (d) no identifier appears in error messages or logs.
5.4 Sub-processors. Arbling uses the sub-processors listed in Annex C and gives the Merchant at least 30 days' advance notice of any new one, so the Merchant may object (clause 8.3).
5.5 Arbling assists the Merchant with data-subject requests as described in clause 7.
5.6 Breach notification. Arbling notifies the Merchant of a personal-data breach affecting this activity without undue delay and in any case no later than 48 hours after becoming aware of it, with the information Arbling then has, followed by updates as more becomes known.
5.7 Deletion and return. Arbling deletes Journey Data on the schedule in Annex B and clause 7. Journey Data consists of pseudonymous, keyed identifiers together with the order id and order value of attributed orders; raw session ids and raw cookie values are never stored, so there are none to return. On termination, records already held run out under Annex B or are erased under clause 7.3.
5.8 Audit cooperation. Arbling gives the Merchant the information reasonably needed to show this processing follows this Addendum, and cooperates with reasonable audits of it.
6. Retention
6.1 Arbling retains each category of Journey Data for the period stated against it in Annex B. Retention differs by record type; no single figure applies across all Journey Data.
7. Data-subject requests and erasure
7.1 Erasure. Arbling's erasure primitive hard-deletes observation rows (events, chat trails, links, continuity records) and identity-redacts retained financial orders (journey reference and correlators set to null, money fields kept), then writes tombstones to stop the erased handle being re-linked or re-minted, plus an append-only, identifier-free receipt.
7.2 Scope. A request citing one handle (session, chat, journey or order) reaches every row correlated to it, across the correlation graph.
7.3 Shopify merchants. Arbling honours Shopify's mandatory webhooks: customers/data_request, customers/redact, and shop/redact (fired about 48 hours after uninstall). On shop/redact, the store's Journey Data is erased and order journey references cleared.
7.4 Arbling holds only pseudonymous, keyed identifiers and the order marker, and cannot identify a shopper from a name or email. The Merchant, as controller, supplies the handle needed (for example, the order id), or routes the request through clause 7.3. Where Arbling genuinely cannot identify the data subject, it records that inability.
7.5 The Merchant sends its own requests concerning Journey Data to hi@arbling.com.
8. Sub-processors and international transfers
8.1 Arbling uses the sub-processors listed in Annex C for this activity. LLM providers (for example, OpenAI) are sub-processors for Arbling's catalog and AI Seller features only, not for journey attribution; Journey Data is never sent to an LLM provider.
8.2 Locations and transfer mechanisms. (a) Arbling Inc. is established in Canada; Commission Decision 2002/2/EC (adequacy for recipients subject to Canada's PIPEDA) applies to transfers from the EU to Arbling in Canada, and the Commission's first periodic review of 15 January 2024 (COM(2024) 7 final) reaffirmed it. (b) Journey Data is processed and stored in the United States by the two sub-processors in Annex C: Railway (application hosting, region US West, California, USA) and MongoDB, Inc. (Atlas database, Ashburn, Virginia, USA, AWS us-east-1). Both are Active participants in the EU-U.S. Data Privacy Framework, its UK Extension and the Swiss-U.S. DPF (dataprivacyframework.gov list, checked 2026-09-16), and each vendor's data processing agreement additionally incorporates the Standard Contractual Clauses (Decision (EU) 2021/914) for transfers not covered by the DPF. For EU/UK/Swiss data subjects, Arbling relies on the DPF certification of each sub-processor, with the SCCs in each vendor's DPA as the fallback mechanism. (c) The Merchant, as controller, is responsible for its own transfer mechanism to Arbling where its data subjects are outside Canada's adequacy scope.
8.3 Arbling gives the Merchant at least 30 days' notice of any new sub-processor for this activity before it starts processing, and the Merchant may object; if the objection cannot be resolved, the Merchant may terminate this processing under clause 9.
9. Switches, suspension and termination
9.1 The Merchant can disable this processing in Arbling at any time. Arbling holds an administrative kill switch per Merchant and a global switch. Switching off stops new processing at once; existing continuity cookies still expire within 24 hours (clause 3.3(c)).
9.2 The Merchant can withdraw at any time by disabling the storefront privacy configuration or uninstalling the Storefront Script. Uninstall triggers deletion under shop/redact about 48 hours later (clause 7.3).
9.3 If the Merchant's accepted Terms version differs from the current version, the Merchant's status is pending_terms, and this processing cannot start or continue until the current version is accepted.
10. Acceptance and versioning
10.1 This Addendum is a schedule to the Terms, accepted by the Merchant inside Arbling before the Storefront Script can run.
10.2 The current Terms version is a server setting. Publishing this Addendum creates a new Terms version, which the Merchant must accept for this processing to start or continue.
Annex A — Data categories
| Category | What it is | Notes |
|---|---|---|
| Session hash | A keyed (HMAC) hash standing in for the shopper's browsing session | Never the raw session id |
| Product identifiers | The product handle / product id of pages the shopper viewed | |
| Timestamps | When events happened (UTC) | |
| Referral signal | How the visit arrived (for example, that it came from an AI assistant), as a coarse signal | |
| Continuity cookie | One first-party cookie named __Host-arb_w2_v1 | See clause 3.3 |
| Keyed link | A keyed (HMAC) link between the visit trail and an order | Never a raw identifier |
| Order marker | The order id and order value of an attributed order | No payment details, no card data |
| Compliance receipts | Identifier-free records that erasure / deletion jobs ran | Contain no personal data |
Not processed under this activity: names, email addresses, postal addresses, payment details, card data. If the Merchant's platform sends such fields in an order webhook, they are not retained in the Journey Data records.
Annex B — Retention register
| Layer | Purpose | Retention |
|---|---|---|
Aggregate daily rollups (journey_daily_rollups) | Year-over-year / season comparison of AI-referred traffic | Indefinite; aggregates carry no identifiers |
Event detail (agent_events) | Per-journey drill-down; dispute / data-subject-request evidence | 180 days from the event (configurable upward only; 180 is the floor) |
| Full-precision window | Near-term funnel investigation | Events are coarsened after 45 days (precision reduced, not retention). This coarsening job is currently dark, pending founder/legal sign-off |
Chat trails (ai_trails) | Per-journey dispute / data-subject-request evidence, support | 180 days |
Widget chat log (embed_chat_log) | Rate-limit and short audit evidence | 25 hours |
Journey ↔ event links (journey_event_links) | Linking chat events to a journey and to an order | 180 days from the event; a link attached to an order is held until that order's marker reaches its own 180-day deadline, then released |
Continuity cookie record (journey_visitor_continuity) | Resolving the live chat handle on the same site | 24 hours absolute; 5-minute provisional state; deleted earlier on withdrawal / revoke / configuration replacement / erasure / uninstall |
Order journey marker (agent_orders.journey_ref) | Order-side evidence, billing basis | The journey reference on an order is cleared 180 days after attribution; the financial order row itself is kept per Arbling's billing retention (see Arbling Privacy Policy, "Data retention & deletion"). A temporary derived repair payload may exist for at most 30 minutes and is erased sooner on success, erasure or uninstall |
Erasure tombstones (journey_key_tombstones) | Prevent an erased handle from being re-linked or re-minted | Indefinite, by design; contain no raw identifier |
Erasure receipts (journey_erasure_receipts) | Append-only proof that erasure / data-subject-request handling ran | Indefinite, by design; only a keyed hash of the handle, never the raw handle |
| Scheduler receipt | Identifier-free proof the retention job completes | Latest row only; no identifiers |
Annex C — Sub-processors
| Sub-processor | Service | Data it touches for this activity | Location | Transfer basis |
|---|---|---|---|---|
| Railway Corporation (San Francisco, USA) | Application hosting and environment secrets; Railway's own hosting provider is Google Cloud Platform (per Railway's published sub-processor list) | All Journey Data in transit through the application | Railway region "US West" (California, USA); both Arbling services run there (measured from the deployment manifests, 2026-09-16) | EU-U.S. DPF, UK Extension, Swiss-U.S. DPF (Active, certified 2024-03-15); SCCs in Railway's DPA as fallback |
| MongoDB, Inc. (New York, USA) — MongoDB Atlas | Database hosting | All Journey Data at rest | Ashburn, Virginia, USA (AWS us-east-1); the cluster's region is fixed at creation (measured 2026-09-16 from MongoDB's registered IP allocation and published geofeed) | EU-U.S. DPF, UK Extension, Swiss-U.S. DPF (Active); SCCs in MongoDB's DPA as fallback |
LLM providers (for example, OpenAI) are sub-processors for Arbling's catalog and AI Seller features only. They are not sub-processors for this activity, and Journey Data is never sent to them.
