Privacy

Two different relationships run through this app, and the difference matters for your rights.

For shopper data, the merchant is in charge and we act on their instructions. A store owner decides to install Ezzeefy, decides what campaigns run, and decides what gets collected. In data-protection terms the merchant is the controller and we are their processor. If you are a shopper and you want your data corrected or erased, the store you shopped with is the right first contact — though you can also reach us and we will route it.

For merchant account data, we are in charge. That covers the store domain, the access credentials Shopify issues us at install, billing state, and the audit trail of actions taken inside the app.

Data arrives from three places: Shopify sends us store records, the storefront sends us activity, and shoppers type things into forms.

We do not store payment card details, and we never receive them — payments are handled entirely by Shopify and its payment providers.

Two separate pieces of code run on a merchant's storefront, and they behave differently on consent. We describe both because describing only the stricter one would misrepresent what happens.

The Web Pixelruns in Shopify's sandbox and is tied to the shopper's analytics consent. If analytics consent has not been given, it does not set a visitor cookie, does not read campaign parameters, and does not attach any customer details. It still reports that an event happened, with no identifiers, so merchants can count traffic.

The theme extension powers on-site personalization and popups. It checks Shopify's consent API before running, but if that API is unavailable or errors, it proceeds rather than stopping, and it reads the preferences consent category rather than the analytics one. So on a store where the consent API is not present, personalization can run and set its identifiers without an explicit signal.

Where the shopper is signed in and consent allows it, the pixel also sends that customer's email and name so activity can be attached to the right person.

These are set on the shopper's device by the merchant's storefront.

One identifier lives outside the browser. The visitor ID is also written into the Shopify cart as a hidden attribute, which means it is carried onto the resulting order. It therefore survives clearing cookies, and it exists inside the merchant's own Shopify order records. It is used to connect a purchase back to the browsing that led to it.

Visitor IDs are not names, but we keep a map linking a visitor ID to a customer once a shopper identifies themselves. While that link exists, the activity behind a visitor ID can be traced to a person, so we treat it as personal data rather than calling it anonymous.

No cookies are set on the merchant's browser by this app. The admin interface authenticates with Shopify session tokens.

From order and activity history we calculate values describing a customer: how recently and often they buy and how much they spend, a lifecycle stage, an estimate of how likely they are to lapse, a likelihood-to-buy score, and a predicted lifetime value. These are recalculated on a schedule and used to decide who receives which campaign and who sees which storefront content.

These are calculated with published arithmetic on the data described above — weighted formulas, not a machine-learning model, and no external service is involved. They influence marketing and on-site content only. They are never used to decide anything with a legal or similarly significant effect on a person.

We do not sell personal data, and we do not share it for advertising. These providers process it so the app can function.

Shopify itself is not listed as a sub-processor because it is the source of the data and the merchant's own platform.

Whether a signed data processing agreement is in place with each of these is [ owner: DPA status per sub-processor ].

Three things are worth stating outright, because privacy policies commonly claim them and we would be overclaiming if we did.

• No data goes to any AI provider. The app has no integration with OpenAI, Anthropic or any other model provider. The scores described above are computed in-house.
• IP addresses are not anonymised. We store an IP address in exactly two situations — when someone submits a form and when someone sets a marketing preference — because it is evidence of when and where consent was given. It is stored as given. IP addresses are not stored for analytics.
• Do Not Track signals are not honoured. The app does not currently respond to browser Do Not Track headers. Consent is handled through Shopify's customer privacy controls instead, as described above.

Some activity data expires on a schedule. A nightly job removes it.

Everything else is kept for as long as the app is installed. That includes customer records, orders, consent records, form submissions, sending history and suppression lists. There is no timed expiry for these — they are removed when a deletion request arrives or when the app is uninstalled, as described next. The map linking visitor IDs to customers also has no timed expiry, so it can outlast the activity data it refers to.

Shopify notifies us automatically when a shopper requests their data or an erasure, and when a store uninstalls. We act on all three.

When a shopper requests erasure, we delete their consent records, opt-in records, form submissions, sending history and delivery events, stored traits, journey enrolments, the customer record itself, and — via the visitor ID map — their storefront events, behaviour summaries, product affinities and personalization records. The map entry is deleted too.

Two things deliberately survive an erasure. Suppression entries are kept, because deleting the record that someone opted out is the fastest way to email them again by mistake — we keep the minimum needed to keep honouring it. Order records are kept because merchants have accounting and legal obligations attached to them, and Shopify remains the authoritative copy.

When a store uninstalls, we delete that store's data — including suppression lists, since there is no longer anything to send from — along with the stored access credentials, and then remove the store record itself, which cascades to anything still attached to it.

When a shopper asks what is held, we assemble their consent records, opt-in records and stored traits, together with counts of messages sent, forms submitted and journeys entered, and make that available to the merchant to pass on. We do not contact shoppers directly, because the relationship is with the store.

Email and SMS are treated differently, deliberately.

Email follows an opt-out model. Anyone recorded as unsubscribed, invalid or erased is excluded from every send and that cannot be overridden. Confirmed opt-in is available and merchants can require it, but it is not enforced on every list — subscribers gathered before it was enabled are not retroactively re-confirmed.

SMS fails closed. If we do not hold an affirmative record of consent for that number, no message is sent. Holding a phone number is not treated as permission. Replying STOP suppresses the number immediately, and suppression is rechecked again before any retry.

Every marketing email links to a preference centre where a recipient can change or withdraw consent. That link carries a signed token identifying the store and address, so no account or password is needed, and the address is taken from the verified token rather than anything typed into the page.

Data is encrypted in transit and at rest by our database provider. Access credentials issued by Shopify are stored server-side and never exposed to the browser. Incoming requests from Shopify are verified cryptographically before they are acted on, and storefront endpoints are rate limited. Actions merchants take inside the app are recorded in an audit trail that stores identifiers and what changed, not the underlying content.

Where data is physically stored is [ owner: database region and data residency ].

Our providers may process data outside the country a shopper is in. The safeguard relied on for transfers out of the UK or EEA, and our representative there if one is required, is [ owner: transfer mechanism and EU/UK representative ].

Depending on where you live you may have the right to see the data held about you, correct it, have it deleted, object to how it is used, receive a copy in a portable form, or withdraw consent you gave earlier. You will never be treated differently for exercising any of them.

If you are a shopper, contact the store you shopped with — they decide what happens to their customer data and can raise the request through the app. You can also reach us via our support page and we will pass it on. If you are a merchant, contact us directly.

If you are in the UK or EEA and think a request was handled badly, you can complain to your national data protection authority.

The app is sold to businesses and is not directed at children. We do not knowingly collect data from anyone under 16. If you believe a child's data has reached us through a store, tell us and we will delete it.

If this policy changes in a way that materially affects how data is handled, we will update the date at the top and notify merchants through the app before it takes effect. Continuing to use the app after that means the updated version applies.

Ezzeefy is operated by [ owner: registered legal entity name ], at [ owner: registered business address ]. This policy is governed by the law of [ owner: governing law and jurisdiction ] and takes effect on [ owner: effective date ].

For anything on this page, reach us via our support page. Our terms cover use of the app itself.