Privacy Policy

1. Introduction

MRKT Mesh is a server-side conversion tracking platform operated by Language Commerce Inc (“we,” “us,” or “our”). It helps e-commerce merchants measure conversions on their own stores and, when a merchant chooses, deliver conversion events to marketing platforms the merchant has configured. This Privacy Policy explains what information the service handles, how it is protected, and the choices available to merchants and to their customers.

2. Roles: Merchants, Shoppers, and Us

Three groups of people interact with MRKT Mesh, and our role differs for each:

• Merchants and their staff (dashboard users): we are the data controller for the account information you give us directly.
• Merchants’ customers (shoppers on a merchant’s store): the merchant is the data controller; we act as a data processor, handling shopper data only on the merchant’s instructions to provide the service. Our Data Processing Agreement governs this processing.
• Visitors to this website: browsing our public pages requires no account and sets no marketing cookies.

3. Information We Collect

a. Account information (from dashboard users directly)

• Email address and name
• Password, stored only as a bcrypt hash — we never store plaintext passwords — or, if you sign in with Google, no password at all (see the Google User Data section below)
• Organization name and role (used for access control)

b. Store data (from a merchant’s Shopify store)

We subscribe to exactly four Shopify webhook topics: order creation, order updates, checkout creation, and refunds. Our requested API access is deliberately minimal — read access to orders, products, and checkouts. We do not request Shopify’s customer-data API scope, and we do not subscribe to customer webhooks. From these webhooks we retain:

• Order details: order ID, line items, totals, currency, order status
• Customer email and phone only as SHA-256 hashes, created at the moment of ingestion for conversion matching. Raw email and phone are never persisted (see Section 4).
• Customer name and address are not requested, not processed, and not stored. If they appear incidentally in a webhook payload they are stripped before the payload is stored or queued.
• Attribution data the merchant’s storefront recorded (UTM parameters, click IDs, landing page, referrer)

c. Storefront visitor data (from the merchant’s data layer script)

Merchants may install our JavaScript snippet on their storefront. On that merchant’s domain it collects:

• A first-party identifier cookie (_mrkt_uid) to recognize returning visitors for attribution
• Advertising click identifiers present in URLs (fbclid, gclid, ttclid) and the Meta browser cookies (_fbp, _fbc) where present
• UTM campaign parameters, page URL and title, referrer, and landing page
• Shopping activity: products viewed, cart actions, checkout steps, purchases
• The visitor’s consent state, read from the store’s consent platform where one is present (Shopify Customer Privacy, Cookiebot, or OneTrust) and recorded with each event
• On the order confirmation page, the store’s numeric customer ID and the checkout email; the email is converted to a SHA-256 hash on our servers and the raw value is discarded

The snippet does not read IP addresses or browser details itself. Our servers derive the IP address and user agent from the incoming request (client-supplied values are rejected) because destination platforms use them for conversion matching.

d. Service usage and audit data

• Configuration changes in the dashboard (for example connecting a destination) are recorded in an append-only audit log that stores who did what and when — never credential values
• Delivery and accuracy metrics about the merchant’s own event flow

4. How We Protect Customer Personal Data

Every payload that enters the system — webhook or storefront event — passes through a default-deny sanitization boundary: instead of removing known-bad fields, we rebuild each payload from an explicit allowlist of safe fields, so anything unexpected is dropped rather than stored. At this boundary:

• Email and phone are normalized and SHA-256 hashed; the raw values are never persisted, displayed, or sold
• Name and address fields (including nested billing/shipping blocks) are removed
• Payment details are removed
• Retained text fields are screened so that stray email addresses, phone numbers, street addresses, or credentials cannot pass through inside them

5. The Shopify Customer ID

One customer identifier is deliberately retained in its original form: the store’s numeric Shopify customer ID. We keep it unhashed for three reasons: it links a shopper’s browsing session to their later purchase; it distinguishes new from returning customers; and — most importantly — it is the key by which we find and erase a customer’s records when Shopify sends a GDPR redaction request (Section 12). When this identifier is sent to Meta for conversion matching, it is SHA-256 hashed at the point of egress.

6. How We Use Information

• To measure conversions and attribution for the merchant’s own store
• To deliver conversion events to the marketing destinations the merchant has explicitly configured and enabled
• To monitor delivery accuracy and system health, and to alert the merchant’s operators when something breaks
• To send service-related (not marketing) communications

And what we do not do:

• We do not sell personal data
• We do not combine one merchant’s data with another’s
• We do not use shopper data to build advertising profiles, train machine-learning models, or for any purpose beyond providing the service to the merchant

7. Where Data Goes: Destinations You Configure

Event delivery is entirely merchant-controlled: no event leaves the platform for a marketing destination unless the merchant has connected that destination and enabled forwarding for their store. Destinations are services the merchant directs us to send data to — each operates under its own terms and privacy policy. The currently supported destinations, and exactly what identity data each can receive:

• Meta Conversions API: SHA-256-hashed email and phone, the SHA-256-hashed store customer ID, Meta’s own browser identifiers (fbp/fbc), IP address, user agent, order details, and the page URL with query parameters stripped
• Google Analytics 4: no email or phone in any form — pseudonymous identifiers (the analytics client ID and the store’s customer ID) and order details
• TikTok Events API: SHA-256-hashed email and phone, a pseudonymous identifier, the TikTok click ID, IP address, user agent, and order details
• Klaviyo: no email or phone in any form — a pseudonymous identifier and order details

Raw email, raw phone, names, and addresses are never sent to any destination — the hashes above are created precisely so the raw values never leave. Google Ads delivery is not currently offered.

8. Google User Data

The only Google user data MRKT Mesh obtains through Google APIs is the basic profile of a dashboard user who chooses “Sign in with Google”: their Google account email address and name, via the standard OpenID sign-in scopes. We use this data solely to authenticate that user to their MRKT Mesh dashboard account and to display who is signed in.

MRKT Mesh’s use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. Specifically: we do not sell Google user data; we do not use it for advertising; we do not use it to train machine-learning or AI models; we do not transfer it to third parties except as necessary to provide sign-in (or as required by law); and no humans read it beyond what account administration requires. We do not request access to Gmail, Drive, or any other Google service data.

9. Meta Platform Data

MRKT Mesh handles Meta Platform Data in accordance with the Meta Platform Terms. What we receive from Meta’s APIs is narrow: when a merchant connects Meta, we verify their access token’s validity and permissions and confirm the configured pixel/dataset is reachable — reading only the validity result, never storing API response bodies. When the merchant enables delivery, we send conversion events to Meta on the merchant’s behalf (Section 7) and process Meta’s acceptance responses to record delivery status. Merchant credentials for Meta are stored encrypted (Section 13). We do not sell Meta Platform Data and do not use it for any purpose other than providing the service to the merchant who connected it.

10. Infrastructure & Storage

The service runs entirely on Google Cloud Platform in the United States (us-east1 region): our application, database, queue, and analytics warehouse all live there. The analytics warehouse (BigQuery) stores event records whose identity fields are limited to hashed or pseudonymous identifiers — never raw email or phone. Our current subprocessors are listed at /subprocessors.

11. Data Retention

• Event, delivery, and session records: deleted automatically by a scheduled job after 90 days
• Queue and transient processing records: pruned automatically (completed jobs within roughly a day, failed jobs within a week)
• Analytics warehouse records (hashed or pseudonymous identity only): retained for as long as the merchant uses the service; deleted on request
• Audit log: retained as an append-only record of configuration changes (it contains no customer personal data and no credential values)
• Account data: retained while the account is active; removal on request via the contact below

12. Deletion & Your Rights

For shopper data, deletion is automated through Shopify’s mandatory GDPR webhooks, and we describe here exactly what each does:

• Customer erasure (customers/redact): we delete the customer’s session records and remove all identity data from their event records; the de-identified commerce records (order totals, timestamps) remain for the merchant’s aggregate reporting
• Store erasure (shop/redact, sent after a merchant uninstalls): we delete the store’s events, sessions, delivery records, and store registration entirely
• Data access requests (customers/data_request): we acknowledge the request and fulfill it through our support process — shoppers should direct access requests to the merchant they bought from, who is the controller of their data

Dashboard users can correct their account details in settings and can request account deletion at privacy@mrktmesh.com. EU/EEA and UK residents have rights under the GDPR, and California residents under the CCPA/CPRA, including access, correction, deletion, and objection; we honor these whether you contact us or the merchant you shopped with. [COUNSEL: statutory recitals and any required jurisdiction-specific disclosures.]

13. Security

• Destination credentials and store API tokens are encrypted at rest with AES-256-GCM
• Customer email and phone exist in our systems only as SHA-256 hashes, created at ingestion
• Dashboard passwords are hashed with bcrypt
• All data in transit uses HTTPS/TLS; incoming Shopify webhooks are authenticated by HMAC signature
• Dashboard access is role-based; sensitive configuration changes require owner/admin roles and are recorded in the append-only audit log
• Our own service secrets (database credentials, signing keys) are provisioned through Google Secret Manager; merchant destination credentials are stored encrypted in our database as described above — never in code or configuration files

14. Cookies & Consent

• Our dashboard uses session cookies for authentication only.
• On merchant storefronts, the data layer script sets one first-party cookie (_mrkt_uid) on the merchant’s own domain to recognize returning visitors, and reads the Meta cookies where Meta’s pixel has set them. It is not a third-party tracking cookie and does not follow shoppers across unrelated sites.
• The script integrates with the store’s consent platform (Shopify Customer Privacy, Cookiebot, or OneTrust) and records the visitor’s consent state with each event. Where no consent platform is detected, events are collected by default — merchants operating in jurisdictions that require prior consent are responsible for running a consent platform on their storefront, and their obligations are described in our Terms.

15. International Data Transfers

Data is processed and stored in the United States on Google Cloud Platform. For personal data originating in the EU/EEA or UK, transfers rest on Standard Contractual Clauses as incorporated in our DPA and in Google Cloud’s data processing terms. [COUNSEL: confirm transfer mechanism and any supplementary measures.]

16. Children’s Privacy

The service is a business tool and is not directed at children under 16. We do not knowingly collect personal information from children; if you believe a child has provided us personal data, contact us and we will delete it.

17. Changes to This Policy

When this policy changes we update the version number and last-updated date shown at the top of this page, and give account holders advance notice of material changes before they take effect.

18. Contact

For privacy questions, data-subject requests, or account deletion: privacy@mrktmesh.com

Language Commerce Inc