Privacy Policy
Last updated: 12 September 2026
Address-access clarification: 4 October 2026.
In one paragraph. Savrena is conversion tracking, recovery, deduplication and delivery reporting for Shopify stores. At launch, merchants can connect Meta Conversions API, Google Ads and Google Analytics 4. We do not sell data, build cross-merchant profiles, or use one merchant's data to serve another. Supported contact details collected by the browser pixel are hashed before transmission. Contact details received through an authenticated server webhook are converted to match identifiers on intake and removed from the diagnostic payload before it is stored.
1. Who we are
Savrena is operated by 95 Info Services, India ("Savrena", "we", "us"). This policy covers the Savrena website at savrena.com, the Savrena console, the Savrena Shopify app, and the tracking scripts and server endpoints that make up the service.
2. Our role: processor for merchants, controller for accounts
Our role depends on whose data it is.
- Shopper data — we are a processor. When a shopper browses or buys from a merchant's store, the merchant is the controller of that data. We process it only to carry out the merchant's tracking configuration, on their instructions. The merchant is responsible for having a lawful basis, for their own privacy notice, and for collecting consent where it is required.
- Merchant account data — we are the controller. For the account details of the merchant or agency using our console (name, email, store connection, billing status), we decide the purposes and are the controller.
3. What we collect
3.1 Merchant account data
- Account email address and password hash
- Organisation and store names, Shopify store domain and access token
- Destination credentials you enter (advertising platform access tokens, API keys, conversion IDs) — stored encrypted at rest
- An audit log of configuration changes made in the console
- Optional alert and report email addresses
3.2 Shopper data from the browser pixel
When a merchant enables our storefront pixel, we receive, for each tracked event:
- Page URL, referrer, event name, timestamp, and product/order details such as item IDs, quantities, value and currency
- Advertising click identifiers present in the URL or in first-party cookies set by the advertising platforms (for example
gclid,wbraid,gbraid,fbclid,_fbp,_fbc) and UTM campaign parameters - A first-party Savrena identifier (see section 7)
- Browser user agent and screen characteristics
- Hashed contact details — where Shopify makes an email address, phone number or name available to the pixel, supported values are normalised and SHA-256 hashed in the browser before transmission. The readable value never leaves the shopper's device via the pixel.
3.3 Shopper data from server webhooks
We also receive events directly from Shopify and, where the merchant uses one, from their third-party checkout provider. This is the part of the service that works when the browser cannot — it is how a purchase is recorded for a shopper who completes checkout off-site or on a device where scripts are blocked.
These webhook payloads reach us in Shopify's or the provider's own format. Depending on that source and Shopify's protected-customer-data decision, they can contain email, phone, name and address fields. We derive the permitted match identifiers and then remove personal fields from the diagnostic copy before it is stored: readable email, phone, names, street address lines, company and precise coordinates are excluded from retained diagnostic data. The app requests Shopify's protected customer Address category solely for city, province/state, postal code and country matching and reporting from permitted sources. Shopify groups street and postal fields in that category, but Savrena does not use street address lines or retain or transmit them for matching. A request is not Shopify approval; missing permission or fields do not stop order capture, recovery or deduplication.
We keep the redacted diagnostic copy for merchant troubleshooting and recovery during the bounded detail period in section 9. Browser and server field availability are measured separately. If Shopify does not approve a requested field, order capture, recovery and deduplication continue; the merchant sees a pending, partial, denied or unexpectedly-missing setup status instead of a false success state.
3.4 IP address and approximate location
We record the IP address the event arrived from. Where destination-specific consent permits it, the address can be used to derive an approximate country/region/city and can be forwarded to a destination that uses it for conversion matching or fraud checks. Reduced and withheld delivery paths remove it. We use a local IP-to-location database; no lookup is sent to a third party.
3.5 Website visitors
Our own marketing pages carry no analytics, no advertising tags and no third-party scripts. Standard server logs are kept for security and reliability.
4. How we use data
- To deliver conversion and analytics events to the destinations the merchant has configured
- To deduplicate events so a single purchase is not counted twice across browser, server and checkout sources
- To attribute an order to the marketing touchpoints that preceded it, and to produce the merchant's reports
- To show the merchant the exact payload we sent to each destination, and to reconcile it against their real orders
- To detect bot and invalid traffic so it is not sent onward as a real event
- To operate, secure, support and bill the service
We do not sell personal data, share it for cross-context behavioural advertising of our own, build profiles that span merchants, or use one merchant's data to benefit another.
5. Who we share data with
Event data is shared only with an advertising or analytics destination that the merchant chooses and connects with their own credentials. The launch destinations are:
Meta (Conversions API) · Google Ads · Google Analytics 4
Each of those platforms acts under its own privacy policy and terms once it receives the data.
We use Hostinger for infrastructure hosting and Cloudflare for DNS, reverse proxy, TLS edge and traffic protection. We also use Cloudflare R2 to store off-site backups of the database, so that a failure of the server does not lose a merchant's history. A backup is a complete copy of the database and therefore contains the same data the service holds. Cloudflare encrypts every stored object at rest automatically, using AES-256; the keys are managed by Cloudflare. Backups are taken daily, the 30 most recent are kept, and older ones are deleted automatically.
The current Subprocessor Register names each provider's purpose and processing location, including the backup storage. Our PostgreSQL database and Dokploy deployment software run in the Hostinger environment rather than with separate managed providers.
We may disclose data where required by law, or in connection with a merger or acquisition, in which case we will give notice before your data becomes subject to a different policy.
6. Google user data
When a merchant connects Google Ads, they grant Savrena access through Google's own consent screen using the https://www.googleapis.com/auth/adwords scope. Google requires this to be stated plainly, so here is exactly what that grant does and does not allow.
- What we access. Only Google Ads data the granting account can already see: the advertising accounts that grant can reach (their customer IDs and account names), and the conversion actions inside the account the merchant selects. We do not request or receive the Google account's email address, profile, contacts, Gmail, Drive, or data from any other Google service.
- What we store. The OAuth refresh token, encrypted at rest, together with the customer ID and conversion action ID the merchant chose. The token is what lets us upload later conversions without asking the merchant to sign in again.
- What we use it for. One purpose only: uploading the merchant's own conversions into the merchant's own Google Ads account, and showing the account and conversion-action pickers during setup.
- What we never do. We do not sell Google user data, use it to advertise our own products, transfer it to data brokers, build profiles from it, or use it to train machine-learning or AI models. It is not shared with anyone other than Google itself when a conversion is uploaded, and the infrastructure providers who host the encrypted record under contract.
- How to revoke. Disconnecting Google Ads in Savrena stops all uploads immediately. A merchant can also revoke the grant directly from their Google account's third-party access page at
myaccount.google.com/permissions. Either route makes the stored token unusable, and uninstalling the app deletes it.
Savrena's use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.
7. Hashing and consent signals
- Email addresses and phone numbers collected by the pixel are SHA-256 hashed in the shopper's browser. Our identity records store the hash, not the address.
- Phone numbers are normalised to E.164 before hashing so the same number matches consistently.
- Consent signals, including Google Consent Mode v2 values where supplied, are evaluated separately for each destination before enrichment, transformation or transmission. Depending on the signal, jurisdiction and destination, an outgoing copy is full, restricted, reduced, or withheld.
- For denied, revoked or opt-in-unknown signals, Meta is withheld unless a verified limited-data-use path applies; Google Ads is reduced to a permitted click identifier or withheld; and GA4 receives reduced event-scoped commercial measurement without shopper identity, geography or page context.
- Canonical order capture and deduplication continue when a destination copy is reduced or withheld. The delivery report records the factual outcome.
- The merchant remains responsible for configuring Shopify Customer Privacy and a lawful storefront consent experience.
8. The Savrena first-party identifier
Our pixel stores a randomly generated first-party identifier on the store's own domain, valid for up to one year. It contains no personal data and cannot identify anyone by itself. Its only purpose is to connect a later purchase to the earlier visit that led to it — for example an order placed days after an ad click. It is scoped to one merchant's store and is never used to follow a shopper across unrelated sites.
9. How long we keep data
| Data | Retention |
|---|---|
| Purchase summaries | 12 months by default; the merchant may choose a period or explicitly choose indefinite retention. A summary contains commercial totals and timestamps, not payload, match identity, consent state or an external order reference. |
| Browsing, canonical event and delivery detail | 30 days by default; the merchant may select from 1 through 90 days. Increasing the period cannot restore detail already deleted. |
| Redacted raw payload and detailed destination receipt | The same bounded detail period; never indefinite. |
| Hashed identity records and attribution | 400 days from last activity, so late-converting orders can still be attributed |
| Purchase idempotency evidence | 400 days after detail expiry; no payload, match hash or consent state. It prevents a late replay from being re-sent or counted twice. |
| Usage evidence | 24 months after the billing cycle closes, to prevent duplicate Shopify usage charges and resolve billing disputes |
| Financial records | 7 years after the financial year closes, or longer only where law requires; these records do not contain shopper event payloads |
New stores receive the defaults above. Existing stores keep their current policy until a merchant notice starts the documented 30-day transition or the merchant selects the new policy. Shortening a retention period requires a preview and confirmation because it permanently removes data.
Required deletion takes precedence over every period and every merchant choice, including indefinite summaries and billing-related retention. Required deletion records must be replayed after a restore before intake resumes. Backup encryption, expiry and restore controls are production evidence gates and are not established merely by this policy.
10. Test mode
Actual Shopify test-mode orders and Shopify's synthetic “send test notification” are labelled as different kinds of test evidence. Test events can be captured and deduplicated for setup verification, but they are excluded from live merchant reporting, live destination delivery, new-customer calculations and billable order usage. A browser claim alone cannot classify an event as test; only an authenticated Shopify order can promote matching browser evidence into the isolated test domain.
11. Shopify data requests and deletion
We implement Shopify's mandatory compliance webhooks:
shop/redact— we permanently purge all of that shop's data.customers/redact— we delete matching events, summaries, deliveries, attribution, identity links, webhook receipts and usage evidence, and retain only non-reversible deletion evidence needed to prevent erased data from returning through a late replay or backup restore.customers/data_request— we assemble the records associated with identifiers Shopify supplies so the merchant can respond to the customer.
12. Your rights
Depending on where you live, you may have rights to access, correct, delete, port or restrict the processing of your personal data, and to object to it or withdraw consent.
Shoppers: please contact the store you shopped with. They are the controller of your data and we act on their instructions; we will assist them in responding to you.
Merchants and account holders: contact us directly using the details in section 16.
13. Security
- All data is transmitted over TLS.
- Destination credentials are encrypted at rest with authenticated encryption; they are never displayed back in full once saved.
- Console access is protected by password, and administrative access additionally requires time-based two-factor authentication.
- Access to production data is limited to the personnel who need it to operate the service.
No system is perfectly secure, and we cannot guarantee absolute security.
14. International transfers
We are based in India, and our infrastructure providers may process data in other countries. The advertising platforms a merchant connects to are largely US-based and operate globally. Where required, transfers rely on appropriate safeguards such as the European Commission's standard contractual clauses.
15. Children
The service is not directed to children, and we do not knowingly collect their personal data.
16. Changes and contact
If we make a material change to this policy we will update the date at the top and, for significant changes, notify account holders by email.
Questions, requests, or privacy concerns: support@savrena.com
95 Info Services, Block no-67, Jetpur Road, Gujarat Housing Board, Gondal, Rajkot, Gujarat, 360311, India