Version 2.0 — effective 15 September 2026. Supersedes version 1.0 (5 August 2026). A summary of what changed is at the end of this policy.
1. Who we are
OB Session Personalization (the "App", "OB Session") is operated by OBSESSION ECOMMERCE DATA TOOLS LTD, a company registered in Cyprus with registration number HE 496073, with its registered office at Nikola Tsadioti, Pearl Park Block 6, Apartment 115, 8035 Paphos, Cyprus ("we", "us", "our"). References to "we" or "our" in this policy refer to OBSESSION ECOMMERCE DATA TOOLS LTD.
Privacy inquiries can be directed to legal@ob-session.com. Our United Kingdom representative under Article 27 UK GDPR is ASAO DS LTD, 86-90 Paul Street, London EC2A 4NE, United Kingdom (Company number 15072782).
This policy explains how the App handles personal data. It applies to the OB Session application installed on a merchant's Shopify store: shopper data processed on the merchant's behalf, and the merchant's own account and contact data.
It does not apply to the ob-session.com marketing website — visitors to that site, demo requests, and the processors the website itself uses are covered by a separate policy at ob-session.com/privacy. The two are independent: nothing the website uses touches shopper data, and nothing described here applies to website visitors.
2. Our role — controller and processor
For data about shoppers on a merchant's storefront, the merchant is the data controller and OB Session is a data processor, acting on the merchant's documented instructions. Shoppers should refer to the merchant's own privacy notice for the controller-level disclosures that govern their data.
For the merchant's own account and contact data, OB Session acts as a controller.
A Data Processing Agreement (Section 17) sets out our processor obligations in full. To the extent we process shopper data as a processor, that processing is governed by that Agreement with the merchant as controller, and shoppers exercise their rights through the merchant (Section 13).
3. Personalization without identification
OB Session is designed so that personalization does not require identification. The App works only from pseudonymous identifiers and the shopper's own behaviour on the store it is installed on. It holds no name, email address, phone number or account link for any shopper, and never joins its identifiers to the merchant's customer records.
How a returning visitor is recognized. Where the store's customer privacy settings permit
collection (Section 6), the App sets a persistent pseudonymous visitor identifier, stored in a
first-party cookie and in localStorage, retained for up to 365 days on a rolling basis, which
allows the App to recognize a returning visitor across sessions. Alongside it the App holds a session
identifier and a per-tab window identifier, which do not outlive the session or the tab. The
identifiers are randomly generated, host-only, and scoped to a single store: they never cross stores
and are never shared with third parties.
The 365-day period is the period over which a returning visitor's earlier behaviour continues to improve the recommendations served to that visitor. We review it annually.
Shorter-lived configurations — a session-only identifier, or one cleared when the tab closes — are available to merchants on request at legal@ob-session.com. Where agreed, the configuration is recorded for that store in the app admin and forms part of Annex 1 of that merchant's Data Processing Agreement. Shorter-lived identifiers reduce the data processed and shorten retention correspondingly; they also reduce recommendation quality, because a returning visitor is not recognized.
What the App cannot do, and what it can. The App holds no name, email address, phone number or account link for any shopper, and it does not retrieve the merchant's customer records. It does associate a visitor identifier with an order ID when an order is attributed to a recommendation, so that the merchant can be billed and performance measured. That association means we can act on a request about a specific person when the merchant gives us the order ID or the visitor identifier — see Section 14.2.
4. Data we process
4.1 Merchant data
Store information — shop domain, shop name, installation and configuration details.
Merchant account contacts — on installation, Shopify provides the shop owner's or administrator's name and email, which we use to create and administer the account and to send service communications. For this data we act as a controller. Providing this data is necessary for us to enter into and perform our agreement with the merchant; Shopify supplies it on installation, and without it we cannot create or administer the account or provide the App.
Catalog data — products, collections, variants, and metafield definitions, synced read-only via Shopify's Admin API, so that recommendations and analytics can reference the merchant's catalog.
Order records — see Section 4.2. Order records are read from the merchant's store, but they describe a shopper's transaction, so we treat them as shopper data processed on the merchant's behalf rather than as merchant data.
4.2 Shopper data
Processed on the merchant's behalf, keyed only to pseudonymous identifiers, and described here by category (we do not build personal profiles from individual fields, and we do not publish our internal field list or derived feature set):
Pseudonymous identifiers — randomly generated identifiers that distinguish the visitor, the session, and the parts of the page involved in an interaction, used to associate events within a visit and across a returning visitor's visits. They are never linked to a customer account and are scoped to a single store (never shared across merchants).
Interaction and behavioral signals — such as page and product views, clicks, hovers, scrolling, cursor movement, how much of a product card is visible, focus/visibility, browser viewport dimensions, and add-to-cart / remove-from-cart actions. These are essential to the App's function.
Content and commerce context — such as the products and collections viewed, cart contents and amounts on the storefront, and the placement where a recommendation appeared (for example, a widget or the product-listing grid). On product and collection pages this includes attributes of the catalog elements displayed (such as product titles and prices) — properties of the merchant's storefront layout, not information entered by the shopper.
Navigation and traffic context — such as page type, navigation path, referrer, and campaign (UTM) parameters. URLs are recorded path-only: query strings are discarded, apart from pagination and filter state.
Search signals — store search terms, processed as an intent signal and never used to identify a shopper.
Device and locale characteristics — such as user agent, language(s), platform, time zone, and screen dimensions, used to improve recommendation quality.
Order records — order ID, order date, currency, total amounts, and line items (quantity, unit price, discount, product/variant references). Two flags are also read or recorded: a test flag — set by Shopify when an order is placed in test mode — so that test orders are excluded from billing and attribution; and attribution flags, recorded by us to mark whether an order or line item was influenced by one of the App's recommendations. Order records are used to attribute orders to the App's recommendations, to compute billing, and — because a completed purchase is a strong signal — to help train the recommendation model for the merchant's store. No customer fields (name, email, phone, address, or Shopify customer ID) are ever requested or stored. Order records are read through Shopify's Admin API rather than from the storefront, so unlike the behavioural data above they are not gated by the store's customer privacy settings; they are read for every order the store receives while the App is installed.
Attribution records — the association between a pseudonymous visitor identifier and an order ID, where an order is attributed to a recommendation.
Derived signals. From the categories above, OB Session derives behavioral signals and product-recommendation inferences. These are generated by the App; they are not additional data collected from the shopper, and the App's internal feature set is not itemised here. They are shopper data and are retained and deleted as Section 8 provides.
The App's first-party storefront script operates only on permitted catalog pages and does not read account, checkout, or form-input fields.
4.3 What we do not process
- No directly-identifying information — no names, email addresses, phone numbers, or postal addresses of shoppers.
- No payment or credential data — no payment details, no account credentials.
- No active device fingerprinting — no canvas, audio-context, or font-enumeration techniques.
- No cross-site tracking — identifiers are scoped to OB Session and to a single store, and are never shared with third parties for tracking.
- No cross-merchant sharing — no merchant's catalog, products, orders, or shopper data is ever shared with, or made visible to, another merchant, and no recommendation served to one merchant surfaces another merchant's catalog, products or shoppers. A model trained specifically for one merchant is never applied to another. Models that underlie the App generally may be trained on data from more than one store; see Section 5.
- No sale or sharing of data for third-party advertising. We do not sell, rent, or trade merchant or shopper data.
- No IP-based shopper profiling — shopper IP addresses are not logged to identify or profile shoppers; transient infrastructure access logs may contain IPs for security/operational purposes and are retained for no longer than 30 days.
5. How we use data, and our lawful bases
| Purpose | Data | Lawful basis (where GDPR applies) |
|---|---|---|
| Provide and operate the App for the merchant | Merchant + shopper data | Performance of the merchant's instructions (processor); merchant's own basis as controller |
| Administer the merchant's account and send service communications | Merchant account contacts | Performance of our contract with the merchant; our legitimate interests |
| Personalize recommendations and analytics | Shopper behavioral data | The merchant's lawful basis as controller. Storing and reading identifiers on a shopper's device requires the shopper's consent under ePrivacy rules regardless of the basis for the processing that follows; the App collects only where the store's customer privacy settings permit it (Section 6) |
| Keep a store's model current while its recommendation surfaces are switched off | Shopper behavioral data | As above. Collection continues so that recommendations are accurate when a surface is switched back on; a merchant that wants storefront collection to stop disables the App's theme extension, and stops all collection by uninstalling (Section 6) |
| Build and operate the recommendation models serving the merchant's store, including a model trained specifically for that store where one is trained | Shopper behavioral, catalog, and order data | As above. A model trained specifically for a store is used only for that store and is never applied to another |
| Develop, train and improve the models underlying the App, including models trained on data from more than one store | Shopper behavioral and order data | The merchant's instruction as controller (Clause 3.6 of the Data Processing Agreement). No merchant can access or see another merchant's data, and no model serving another merchant reproduces or exposes a store's catalog, products or shoppers |
| Attribute orders and compute billing | Order records and attribution records (no customer fields) | The merchant's lawful basis as controller; we process these records as processor, on the merchant's instructions, in order to perform our contract with the merchant |
| Develop and improve the App, using aggregated, de-identified statistics | Derived from shopper behavioral data; once derived, the statistics contain no identifiers and are no longer personal data | Our legitimate interests (improving the service); the derived statistics themselves fall outside data protection law |
| Maintain security and prevent abuse | Technical/operational logs | Legitimate interests / legal obligation |
The App does not carry out automated decision-making producing legal or similarly significant effects on individuals (Article 22 GDPR); it personalizes the products a shopper is shown.
6. Consent, and when collection runs
How the consent gate works. The App collects behavioural data from a store's pages only where Shopify's Customer Privacy API reports that the processing is permitted for that shopper. That signal reflects the store's own customer privacy settings: in a region the merchant has configured to require consent, the API reports that non-essential processing is not permitted until the shopper gives consent, and the App sets no identifiers and collects nothing until then; in a region the merchant has not so configured, the API reports that processing is permitted by default, and the App collects on that basis. Where the Customer Privacy API is unavailable or returns no signal, the App does not collect.
The merchant, as controller, decides which regions require consent, how consent is collected, and what its own privacy notice says. A shopper who wants to know how a particular store has configured this should ask that store.
If consent is withdrawn. Where the consent signal for a shopper changes so that processing is no longer permitted, the App stops collecting for that shopper and stops setting or reading its identifiers. Data already collected expires under Section 8, and is deleted sooner if the merchant asks us to delete it (Section 14.2).
Order records are not gated this way. They are read from the store through Shopify's Admin API, not from the storefront, so they are read for every order the store receives while the App is installed (Section 4.2).
Stopping collection. Disabling the App's theme extension stops all storefront collection; order records continue to be read until the App is uninstalled. Uninstalling the App stops all collection.
Collection runs for as long as the App is installed and the OB Session extension is enabled in the store's theme. It is not tied to whether recommendations are currently being shown: a merchant who switches recommendation widgets or collection pages off in the app stops those recommendations reaching shoppers, and stops being billed for them, but consented behavioural data continues to be collected so that the store's model stays current. A merchant who wants collection to stop entirely should disable the OB Session extension in the theme, or uninstall the App (Section 8).
7. Cookies and device storage
Where the store's customer privacy settings permit collection (Section 6), the App stores a small amount of first-party data on the shopper's device — solely to maintain continuity of the pseudonymous session, to personalize what is shown, and to remember the consent state. These are not strictly-necessary cookies: they are set only where the consent signal permits it. The App holds:
- a pseudonymous visitor identifier (cookie and
localStorage), retained for up to 365 days on a rolling basis; - a session identifier with an activity timestamp, expiring after 60 minutes of inactivity or with the session;
- a per-tab window identifier, cleared when the tab closes;
- the consent state, held until the shopper's consent signal changes or the visitor identifier expires; and
- a transient queue of pending events, cleared once they are sent and discarded if they are not sent within 7 days.
Where a merchant has agreed a shorter-lived configuration with us (Section 3), the persistent
visitor identifier is not set and the session identifier is stored in localStorage or
sessionStorage instead.
We collect the events described in Section 4.2 via our own first-party storefront script. The
cookies and storage above are host-only (no shared domain), so identifiers never cross stores; they
are set with Secure (on HTTPS) and SameSite=Lax, and contain only a random identifier or
timestamp — no personal information. We do not use third-party cookies or third-party tracking
pixels, and do not use cookies for cross-site tracking.
8. Retention and deletion
Shopper data is retained only as long as needed for the purpose. The maximum retention periods are:
| Data | Retention |
|---|---|
| Recommendation state — the pseudonymous record of a visitor's activity used to personalize their visits, and the current cart | Up to 365 days |
| Behavioral event data, A/B measurements and A/B test assignments | Up to 12 months (rolling) |
| Derived behavioral signals and product-recommendation inferences | Up to 365 days |
| Attribution records (visitor identifier ↔ order ID) | Up to 12 months, and deleted on a customers/redact request for the order |
| Order records (billing, attribution, model training; no customer fields) | Up to 24 months, or earlier on a customers/redact request. Where an order record is the evidence for a fee we charged a merchant, the financial fields are kept for as long as accounting and tax law requires |
| On-device identifiers, consent state and pending-event queue | Per Section 7 |
| Infrastructure access logs (may contain IPs) | Up to 30 days |
| Records of access to shopper data by our personnel | Up to 12 months |
| Merchant catalog/config and model artefacts | While the App is installed; deleted on uninstall |
Where a merchant has agreed a shorter-lived identifier configuration with us (Section 3), the first, third and sixth rows shorten correspondingly. Deletion extends to backups on the next backup cycle, and in any event within 35 days of the deletion being actioned.
On app uninstall, all of a merchant's data is deleted within 30 days, following Shopify's
shop/redact request (Section 13). Aggregated or anonymised data that can no longer be linked to any device or shopper is
not personal data and may be retained and used for internal and statistical purposes, including to
develop and improve the App.
9. Sub-processors
We rely on the following sub-processor to operate the App:
| Sub-processor | Purpose | Location |
|---|---|---|
| Amazon Web Services | All cloud infrastructure — all OB Session processing runs on AWS-native services | AWS regions in the United States and/or the European Union |
Shopify is the platform on which the App runs and is an independent party with its own agreement with the merchant; it is not our sub-processor. We engage no other sub-processor, and we do not send shopper data to any third-party or third-party-hosted model API. The current list is Annex 3 of our Data Processing Agreement, published at ob-session.com/legal/dpa; we give merchants at least 30 days' notice of a change, with an opportunity to object (Clause 6.3 of that Agreement).
This section concerns the App. The ob-session.com marketing website is operated separately and uses its own processors, described in the website privacy policy at ob-session.com/privacy.
10. International data transfers
OB Session is an EU company (Cyprus). The personal data the App processes is hosted on Amazon Web Services. The default region is the United States (us-east-1); hosting in an AWS region in the European Union is available to merchants on request.
We contract with Amazon Web Services EMEA SARL, which is established in the EEA, so engaging AWS is not itself a transfer outside the EEA. Where the Service runs in a US region, the transfer is the onward transfer from Amazon Web Services EMEA SARL to Amazon Web Services, Inc., and relies on the European Commission's adequacy decision for the EU-US Data Privacy Framework, under which AWS is certified (and, for UK data, the UK Extension to it), and/or the EU Standard Contractual Clauses with the UK Addendum in our agreement with AWS. A copy of the relevant instrument is available on request at legal@ob-session.com. Where data is hosted in an AWS region in the EU, no such transfer occurs.
If the adequacy decision for the EU-US Data Privacy Framework ceases to apply, we will within 30 days either move the affected processing to an AWS region in the European Union or tell affected merchants which alternative safeguard we rely on.
11. Security
We apply appropriate technical and organisational measures to protect personal data, as required by Article 32 GDPR — including encryption in transit and at rest, least-privilege access controls with audit logging, and per-merchant data isolation (a model trained for one merchant is never applied to another). Our full security posture is described on our security page (ob-session.com/security), and the detailed technical and organisational measures are set out contractually in the Data Processing Agreement.
12. Automated decision-making and profiling
The App analyses each shopper's own on-store behaviour to predict which products they are likely to be interested in, and personalizes recommendations accordingly. Under GDPR this automated analysis is a form of "profiling" (Article 4(4)) — but it is individual and behaviour-based: the App does not group shoppers into segments or audiences, and does not build demographic or cross-site profiles. This processing does not produce legal or similarly significant effects on any individual (Article 22 GDPR) — it affects only which products a shopper is shown. A shopper can stop it by declining or withdrawing consent where the store's settings offer that choice, and can ask the merchant to have their data deleted — Section 14.2 explains what we can do when the merchant gives us an identifier. Where a merchant relies on legitimate interests for the analysis that follows, a shopper also has the right to object under Article 21 GDPR, exercised with the merchant. A merchant can reduce the processing by agreeing a shorter-lived identifier configuration with us (Section 3), and stop it by disabling the App's theme extension or uninstalling the App. The App does not use this processing for advertising or audience-building.
13. Compliance webhooks and data subject requests
The App subscribes to Shopify's mandatory compliance webhooks:
customers/data_request — when a shopper asks a merchant to view their data, we respond within
the timeframe Shopify requires. Because the App holds no customer-identifying fields, it cannot link
its pseudonymous browsing data to a named individual; where the request identifies specific orders,
we return the order-level records we hold for those order IDs (which themselves contain no
identifying fields).
customers/redact — within the timeframe Shopify requires, we delete the order records
identified in the request, together with the attribution records linking those orders to a
pseudonymous visitor identifier — except that where an order record is the evidence for a fee we
charged a merchant, the financial fields are kept as Section 8 provides. If the merchant asks us to, we also delete the browsing data
associated with that identifier; otherwise it expires under the retention schedule (Section 8).
shop/redact — within 30 days of app uninstallation, we delete all of the merchant's data across
all systems, subject only to records we are required by law to retain, with deletion propagating to
backups as Section 8 provides.
The App holds no customer-identifying field, so we cannot find a shopper's records from a name or an email address, and we are not required to collect extra information in order to be able to (GDPR Article 11). That is a limit on what we hold, not on what we will do: where the merchant gives us an order ID or a visitor identifier, we can locate the associated records and will export or delete them within 30 days. Shoppers wishing to exercise their rights should contact the merchant (the controller); we assist the merchant in responding.
14. Your privacy rights
Which rights apply, and who can fulfil them, depends on your relationship to us. We handle data-subject requests the same way regardless of where the individual is located.
14.1 If you are a merchant — data we control
For the account-contact data we hold as a controller (Section 4.1), you have the GDPR / UK GDPR rights of access, rectification, erasure, restriction, objection, and data portability; the right to withdraw consent where we rely on it (without affecting processing carried out before withdrawal); and the right to lodge a complaint with a supervisory authority (in Cyprus, the Office of the Commissioner for Personal Data Protection). To exercise these, contact legal@ob-session.com; we respond within the period required by applicable law (for GDPR, within one month).
14.2 If you are a shopper — data we process for a merchant
Here we are a processor, so you exercise your rights with the merchant (the controller), and we assist them.
We hold no name, email address or account link for you, so we cannot find your records from your name. What we can do is find them from an identifier. If the merchant gives us an order ID — which Shopify supplies with a deletion request — or the pseudonymous visitor identifier stored in your own browser (you can read it yourself; see Section 7), we will locate the associated records and export or delete them within 30 days. You can supply that identifier to the merchant yourself; GDPR Article 11(2) exists for exactly this situation.
If no identifier is supplied, the data expires on its own under our retention schedule (Section 8).
14.3 United States (California and other states)
For shopper data we act as a service provider to the merchant, and we do not "sell" or "share" personal information as those terms are defined under the CCPA/CPRA and comparable state laws. Where state privacy laws apply (including California, Virginia, Colorado, Connecticut, Utah, and others as enacted), residents have rights to know, access, delete, correct, and opt out of sale/sharing and targeted advertising — none of which we perform. The categories we process, our purposes, and our retention are in Sections 4, 5 and 8.
14.4 Other jurisdictions
Where other data protection laws apply (for example LGPD in Brazil, PIPEDA in Canada, or the Australian Privacy Principles), we honour the equivalent rights and support the merchant's compliance.
15. Children
The App is a business-to-business service and is not directed at children. We do not knowingly process children's personal data. The age of digital consent varies by country (for example, 14 in Cyprus, up to 16 elsewhere in the EEA, and 13 in the United States); because the App cannot determine a visitor's age, the merchant, as controller, is responsible for its store's age and consent requirements and its consent framework.
16. Changes to this policy
We may update this policy from time to time. We give merchants at least 30 days' notice of a material change, in the app admin and by email, and the effective date above is updated. Where a change to the Data Processing Agreement materially reduces the protection given to shopper data, merchants may object and terminate without penalty — see Clause 21 of that Agreement.
17. Data Processing Agreement
A Data Processing Agreement reflecting our processor obligations — including the categories above, sub-processors, international transfers, security measures, and deletion — is published at ob-session.com/legal/dpa and is incorporated into our agreement with each merchant at installation. Questions: legal@ob-session.com.
18. Relationship with Shopify
OB Session operates within Shopify's platform and privacy framework. Merchants and shoppers should also review Shopify's own Privacy Policy and GDPR resources.
19. Contact us
All privacy, data-protection, security and legal correspondence — including data subject requests, Data Processing Agreement questions, sub-processor inquiries, and vulnerability reports — should be sent to legal@ob-session.com.
OBSESSION ECOMMERCE DATA TOOLS LTD · Nikola Tsadioti, Pearl Park Block 6, Apartment 115, 8035 Paphos, Cyprus · Reg. no. HE 496073
What changed in version 2.0
- The identifier tiers are withdrawn. Merchants no longer select one of three identifier tiers at onboarding. The App runs a single configuration — a persistent pseudonymous visitor identifier retained up to 365 days — and shorter-lived configurations are available on request (Section 3).
- Collection and recommendations are separate states. Behavioural data continues to be collected when a merchant switches recommendation surfaces off, so the store's model stays current. Merchants stop collection entirely by disabling the App's theme extension or uninstalling (Section 6).
- How the consent gate works is described accurately — it follows the consent signal Shopify's Customer Privacy API returns for the store's own settings, which permits processing by default in regions the merchant has not configured to require consent (Section 6).
- Order records are described as shopper data processed on the merchant's behalf, and we state plainly that they are read through the Admin API and are not gated by the storefront consent signal (Sections 4.1, 4.2, 6).
- Data subject requests: we now commit to locating, exporting or deleting records where the merchant supplies an order ID or a visitor identifier, rather than relying on pseudonymity alone (Sections 13, 14.2).
- The retention table adds derived signals, attribution records, on-device consent state and the pending-event queue, access logs, and backup propagation (Section 8).
- International transfers: the default region (us-east-1) is now stated, together with the contracting AWS entity, the shape of the transfer, and what happens if the EU-US Data Privacy Framework adequacy decision ceases to apply (Section 10).