Privacy policy

1. Who we are

Dave The Plumber is built and operated by DMT Holdings and Consulting, trading as UN8 Brands, in the United States.

• Contact: david@un8brands.com
• Site: davetheplumber.app

We do not have a Data Protection Officer and are not required to appoint one.

2. What Dave does

Dave The Plumber helps an online store send accurate conversion events to Meta's Conversions API, using the store's own Meta advertising account. It comes in two forms, and this policy covers both:

• The Shopify app, installed from the Shopify App Store.
• The web app at www.davetheplumber.app, which works with any store. The merchant signs in with a link we email them, adds our JavaScript snippet to their store, and sends us their orders by webhook.

Browsers block tracking, so a browser-only pixel under-reports sales and the merchant's ads get worse. Dave records shopping events on the merchant's store, matches them to the merchant's orders, and sends each event to Meta from our server as well as from the browser. Both copies share one event ID, so Meta counts it once. We attach hashed customer identifiers so Meta can match the event to a person it already knows.

The web app also has three optional tools: Seal the leaks (audiences in the merchant's Meta ad account), a cookie-consent banner, and a free accessibility scanner.

3. Our role

For everything about a shopper, the merchant is the data controller and we are a data processor acting on their instructions. The merchant decides to use Dave, decides what it forwards, and answers their own customers' privacy requests.

For the merchant's own account data — their sign-in email, workspace, Meta credentials, plan and billing records, and for the Shopify app their shop domain and Shopify session — we are a controller, because that data is about our business relationship with them.

We are also a controller for scans run on the free ADA scanner (section 12) and for waitlist emails on our marketing website (section 19).

Meta is a separate controller for what it does with the events and audiences it receives. The merchant's relationship with Meta is governed by Meta's own terms, not by us.

Legal basis (GDPR). For shopper data we rely on the merchant's legal basis, which in practice is the shopper's consent, captured by the merchant's cookie banner or by Dave's banner if the merchant turns it on. We read that consent and act on it (section 11). For merchant account data we rely on contract (providing the service) and legitimate interests (security, billing, support).

4. Your account and signing in

4.1 Signing in to the web app

There is no password. You enter your email address and we send you a one-time sign-in link. The email is sent by our email provider, Resend. The link works once and expires after 15 minutes.

• We store your email address and a SHA-256 hash of the link — never the link itself. That record is deleted a day after the link is used or expires.
• When you sign in, your email address is kept on your user account, and we set one cookie, __dave_session. It is signed, cannot be read by page scripts, lasts 30 days, and holds only your user ID and the workspace you are working in.
• Your user account is deleted when you delete the last workspace you belong to (section 14).
• To stop abuse, sign-in requests are counted per email address (from the stored link records) and per network address. The network-address count lives only in server memory and is never written down.

4.2 What we keep about your account

5. Shopper data from the storefront

In the web app, the merchant adds our snippet (dave.js) to their store. In the Shopify app, our Shopify web pixel does the same job. Either one sends us events only for visitors whose consent allows it (section 11). For those visitors we receive:

• The event name and time, an event ID, and the visitor's consent choices.
• Non-personal shopping details: product, variant and collection IDs, collection title, SKU, price, quantity, item count, cart or order value, currency, and on a purchase the order ID.
• The page address with the query string and anything after # removed — in the browser, and again when it reaches us — so search terms and discount codes never reach our database.
• The browser's user agent string.
• Pseudonymous identifiers: Meta's own _fbp and _fbc advertising cookies (_fbc is also rebuilt from the click ID Meta adds to ad links), and a browser ID. In the web app the browser ID is our own first-party cookie _dave_vid, a random value set on the store's own domain. In the Shopify app it is Shopify's per-store visitor ID.
• For a search, only the length of what the shopper typed, never the text.

We do not store IP addresses. The snippet and pixel never read an email, phone, name or address from the page, and never read a logged-in customer record. If an event reaches our server without consent, it is answered like any other and thrown away; nothing is stored.

A visitor who has opted out of the sale or sharing of their data, or whose browser sends Global Privacy Control, is still recorded for the merchant's own reports, but nothing of theirs is sent to Meta (section 11.4).

5.1 What the web app's snippet keeps in the shopper's browser

Visitors in the EU, EEA, UK and Switzerland: nothing is written to the browser before they accept. Until then the browser ID, the click ID and the campaign tags live only in the open page, and are written when the visitor accepts — so an Accept on the page they landed on still keeps the click ID. After a Reject, or with no choice, the only thing stored is _dave_consent, which records the refusal.

Everyone else: _dave_vid, _dave_attr and a rebuilt _fbc are written once the snippet knows the visitor's region, before any consent choice. Nothing is written before the region is known.

None of these is sent to us until consent allows it — with one exception: when the merchant's banner is on, the snippet tells us that a banner was shown, with the browser ID (for an EU visitor, one that exists only in the open page), so the merchant's consent statistics are accurate (section 11).

6. Shopper data from orders

Web app: the merchant sends us orders by signed webhook — from Shopify (orders/create and, optionally, orders/paid) or from any other platform through our generic order webhook. Shopify app: from Shopify webhooks (orders/create, orders/paid, checkouts/update, customers/create). From each order we read:

• The shopper's email, phone, first name and last name, and the platform's customer ID. These are read in memory when the order arrives, hashed immediately, and the plaintext is discarded. It is never written to our database or our logs.
• Order ID, order value, currency, item count, and product IDs with quantities.
• The country code of the shipping or billing address, in memory only, to put the right country dial code on the phone number before it is hashed.
• The shopper's consent choice, if the order carries one (section 11).
• Delivery details: which webhook, when it arrived, how long we took to answer, and the sender's delivery ID. No personal data.

Every order webhook is checked against its HMAC signature before anything is written. There is no database column for the order body.

We do not collect or send postal address fields. Meta's Conversions API accepts city, state, zip and country as optional match keys; our code deliberately does not normalise, hash, store or send any of them.

7. Hashing, and what Meta receives

Before anything leaves our server, each customer identifier is normalised to Meta's published rules and hashed with SHA-256. Email is trimmed and lowercased; phone is reduced to digits with the country dial code applied; names are lowercased with punctuation removed; the customer ID is used as-is.

For each event, Meta receives:

• The hashes — em, ph, fn, ln, external_id — never the plaintext.
• The _fbp and _fbc cookie values, which are Meta's own identifiers.
• The event name, time and shared event ID; the page address and user agent; and value, currency, product IDs, item count and order ID.

Two honest caveats:

• A hash is not anonymity. The same email always produces the same hash, so a hash identifies one person consistently. We treat hashes as personal data everywhere: they are erased on a deletion request, aged out on the retention schedule, and included in a shopper export.
• We hash the customer ID even though Meta accepts it in plaintext. Our database then holds nothing that can be looked up directly in a store's admin. It is a data-minimisation measure, not encryption.

If the merchant uses Seal the leaks, hashes are also uploaded to a customer-list audience in their ad account (section 9).

We do not send data to Google today. Meta is the only live destination. If that changes, this section and the sub-processor list will be updated before it goes live.

8. Identity stitching — what it is, plainly

Identity stitching is an optional setting, off by default and available on paid plans, that a merchant turns on in Settings.

When it is on: after a shopper places an order, we store one row for that browser containing the browser ID and the SHA-256 hashes of the email, phone, name and customer ID from that order. If that same browser comes back and views a product, we can attach those hashes to the new event, so Meta can match a browsing event to a shopper it already recognises.

What it is not:

• It is first-party only. Rows belong to one merchant's store and are never compared, joined or shared across stores.
• It is never cross-site. We do not observe a shopper anywhere except on the store that uses Dave.
• It uses no fingerprinting. There is no canvas, font, device or probabilistic fingerprint anywhere in Dave. The browser ID is a random value in a cookie (web app) or the one Shopify assigns (Shopify app).
• It only ever builds from an order the merchant actually received and a visit that had consent behind it.

A stitched identity is deleted when the merchant switches stitching off, when the shopper's data is deleted, when the merchant deletes their workspace (web app) or uninstalls (Shopify app), and automatically once the shopper has neither ordered nor visited for 90 days.

9. Seal the leaks: connecting your Meta ad account

Seal the leaks is an optional web-app feature. It stops a merchant's prospecting ads paying to reach people who already bought or already follow them. It needs more access than sending events, so it has its own connection: Facebook Login. Meta shows you exactly what is asked for before you agree.

9.1 The permissions we ask for

9.2 What Dave does with them

• Reads your ad accounts (ID and name), your Pages (ID, name and linked Instagram account), your audiences' approximate sizes, and your ad sets (name, status, campaign name and targeting).
• Creates up to six custom audiences in your own ad account, each named "Dave · …": recent purchasers, existing customers, Instagram engagers, Page engagers, ad engagers, and — only if you turn it on — site visitors.
• Uploads a hashed customer list to the existing-customers audience: the hashed email, phone, first name, last name and external ID that Dave already holds from your orders. Only shoppers whose consent allows sending to Meta are included — the same rule used for purchase events, so a shopper who opted out of sale or sharing (or sent Global Privacy Control) is left out. Only SHA-256 hashes are uploaded; the code refuses to send anything that is not a hash. A nightly job adds new customers and refreshes audience sizes.
• Adds the audiences as exclusions only to the prospecting ad sets you tick, and only after you confirm. Exclusions you already had are kept. Unseal removes exactly what Dave added.
• Dave never creates, edits or pauses ads, and never changes budgets or bids.

We use data received through Meta's APIs only to provide this feature to you. We do not sell it or use it for anything else.

9.3 How the connection is stored, and disconnecting

• Meta gives us a long-lived access token. We encrypt it at rest with AES-256-GCM. The key is kept in our server environment, never in the database, a log line or a web page. Screens show only the token's last 4 characters, and the token never reaches your browser.
• Alongside it we keep the ad account ID and name, the Page ID, the Instagram account ID, the permissions Meta granted, when the token expires, and the app-specific Facebook user ID Meta gives us for the person who connected (so a deletion request from Meta can find the connection).
• Disconnect deletes the token and the connection record straight away, and forgets which ad sets were sealed. Deleting your workspace does the same.
• Audiences and exclusions already in your ad account are yours and stay there. To remove them, press Unseal before you disconnect, or delete them in Meta Ads Manager.

10. Deleting your Facebook data

1. Remove the app in Facebook. In your Facebook settings, open the apps and business integrations you have connected, choose Dave The Plumber, and remove it. Meta then notifies us automatically at https://www.davetheplumber.app/meta/data-deletion. We delete every connection made with your Facebook account — the encrypted token, the ad account, Page and Instagram IDs stored with it, and the record of which ad sets were sealed. Meta gives you a confirmation code and a link to a status page on our site where you can check the deletion. If the check cannot finish straight away, the status page says so and we keep checking nightly.
2. Email us at david@un8brands.com and ask us to delete your data. We will delete it and confirm by email.
3. In the web app, press Disconnect on Seal the leaks. The token is deleted at once.

To run the status page we keep the confirmation code, the status, and a SHA-256 hash of your Facebook user ID — never the ID itself and never a token.

This deletes what came from Facebook Login. It does not touch a Conversions API token the merchant pasted into Dave by hand, or the shopper data their store sent us — those are the merchant's to delete (section 18). Audiences Dave created live in the merchant's ad account and are removed in Meta Ads Manager, not by us.

11. Consent and the cookie banner

11.1 Nothing is collected without consent

Web app. The snippet sends an event only when the visitor's choice allows both analytics and marketing. It reads the choice in this order: a choice already made on Dave's banner; Shopify's own consent tool, if the store uses it and the shopper decided there; then, with Dave's banner off, the consent signal the merchant's own banner passes to the snippet. With no signal at all, the answer is "not consented" and our server refuses the event too. Events fired before a choice wait in the page and are sent only if consent is given.

Shopify app. Our web pixel reads each visitor's consent through Shopify's Customer Privacy API — the state the merchant's own cookie banner records. A visitor without both analytics and marketing consent produces no request at all, and consent is re-checked immediately before every event. Our consent gate also suppresses the pixel when a shopper's sale-of-data consent flag is off.

11.2 Dave's cookie banner (web app, optional)

A merchant can turn on Dave's own banner. It is off by default. When it is on, we work out which rules apply from the visitor's country and state, which our host, Vercel, derives from the connection. We keep only the resulting region group, never the network address.

Each choice is recorded, as the merchant's proof of consent: the _dave_vid browser ID, the region group, the three choices (analytics, marketing, sale or sharing), where the choice was made (banner, footer link, Global Privacy Control, or Shopify) and when. We also record that a banner was shown — once per browser tab, or once per page for EU, EEA, UK and Swiss visitors, because nothing is stored in their browser to remember it. No network address, page or user agent is recorded.

11.3 Reject is real

• The browser stops. Nothing more is sent to us, and any events waiting in the page are dropped.
• Recent events are deleted. The browser asks our server to delete that browser's events from the last day. Any of them not yet sent to Meta are withheld.
• The order follows the choice. On Shopify stores with a standard theme, the choice is saved on the cart, so it arrives with the order; the generic order webhook carries it as a field. An order whose choice says no to marketing, or opts out of sale or sharing, is not sent to Meta, whatever the merchant's settings. Shopify Hydrogen stores do not carry the cart attribute unless the merchant adds it.
• Audiences follow it too. A shopper who said no is left out of the merchant's customer-list audience. If they were in it before, Dave asks Meta to remove them. To do that, Dave keeps only the hashed email and phone from that order and sends those hashes to Meta with a remove instruction — never to add anyone, and never in readable form.
• Events Meta has already accepted cannot be recalled by us.

11.4 Sale or sharing, and Global Privacy Control

Sending a shopper's events to Meta for advertising counts as "sharing" under California law. So a shopper who turns off "Sale or sharing" in the choices panel, or whose browser sends Global Privacy Control, is never sent to Meta by Dave:

• Browser. Their events are still recorded for the merchant's own reports, marked with the opt-out, and never forwarded. Any of their events still waiting to go to Meta are held back.
• Order. The opt-out travels with the order, as the Reject does, and the order is not sent. The generic order webhook accepts it as a field. If the order carries no choice but the browser recorded the purchase with the opt-out, the order is held back too.
• Audiences. The shopper is left out of the customer-list audience, and removed if they were in it.

Global Privacy Control is honoured everywhere: in every region, whether or not the merchant uses Dave's banner, and over an earlier choice. Our server also reads it from the browser's request. In the EU, EEA, UK and Switzerland the banner is still shown; accepting there does not turn sale or sharing back on.

11.5 The merchant's part

Consent is captured under the merchant's privacy notice, whether through their own banner or Dave's. The merchant is responsible for a lawful consent mechanism and for telling their shoppers that data is shared with Meta for advertising.

One merchant setting matters here: "Send purchases without a storefront visit." It is off by default. When it is on, an order that arrived by webhook (a draft order, a phone order, a subscription renewal) can be forwarded even though no consented browser visit was recorded for it — with hashed order details only, never a browser cookie. An order that carries a "no" is still not sent.

12. The free ADA scanner

Anyone can scan a website at /ada-scan without signing in. For each scan we store:

• The address scanned, and the site's title.
• The pages checked (address and title).
• What was found: the rule, its severity, how many times, and up to three sample page-element references for each issue — plus the score, grade, how the scan ran and how long it took.

That is only what any visitor to that website can already see. The report lives at its own hard-to-guess address and is public to anyone with the link. We ask search engines not to index reports. Scans started inside the web app are also linked to that workspace.

"Email me this report." If you ask for the report by email, we use your address once, to send the link through Resend, and keep only a SHA-256 hash of it (to avoid duplicates and count requests). We do not add you to any mailing list.

Scans, reports and those email hashes are deleted after 90 days, and a report link stops working then.

To stop abuse, scans are limited per network address. That count lives only in server memory. The scanner visits the website you name and identifies itself as DaveThePlumber-ADAScan/1.0.

13. Billing and payments

• Web app — Stripe. When you subscribe, we create a Stripe customer with your email address and workspace name, and send you to Stripe's own checkout page. Your card details go to Stripe, not to us. We store only Stripe's customer and subscription IDs and your plan. Messages from Stripe are signature-checked before we act on them. You manage or cancel through Stripe's billing page.
• Shopify app — Shopify. Billing runs through the Shopify Billing API. We never see or store a card number.

14. Retention

• Storefront events, order-delivery records and forwarding records (including all hashed identifiers): 90 days. A nightly job deletes them, one store at a time.
• Stitched identities: deleted once the browser has had no order and no visit for 90 days.
• Sign-in links: deleted a day after they are used or expire. The session cookie lasts 30 days.
• Match quality scores: kept for the life of the account. A score is a number about an ad account, not about a person.
• Settings, connections and delivery-health summaries: kept while the account exists, because they describe the current setup.
• Shopper export files: kept on the merchant's Privacy screen until that shopper's data or the workspace is deleted.
• Consent records (section 11): 13 months, then deleted by the nightly job. They are kept longer than events because they are the merchant's proof that a choice was made.
• ADA scans and scan-email hashes (section 12): 90 days, then deleted by the nightly job — scans made in the web app and on the free public scanner alike.

Deleting a workspace (web app, Settings, owner only) erases in one step: connections and credentials, the Meta ad-account connection and audience records, storefront events, order-delivery records, forwarding records, stitched identities, scores, shopper export files, settings and usage counts, consent records, and the workspace's accessibility scans with their email hashes. If that was your only workspace, your user account — your email address — and your sign-in link records are deleted too, and you are signed out. If you still belong to another workspace, your account stays. Our payment-message log keeps Stripe's event IDs so a repeated message is not acted on twice, with the link to the deleted workspace removed.

Shopify app: everything is deleted on uninstall (Shopify sends shop/redact 48 hours after uninstall), and deletable on demand from Settings.

The in-app Privacy screen shows whether the nightly deletion has actually run successfully in the last 3 days, and says so plainly when it has not.

15. Security

• In transit: HTTPS everywhere — stores to us, browsers to us, us to Meta and our providers.
• At rest: Meta access tokens (for both the Conversions API and Seal the leaks) are encrypted with AES-256-GCM. The key lives in the server environment, never in the database, a log line or a page. Screens show only the last 4 characters.
• Nothing that could sign you in is stored readable: sign-in links and API keys are kept only as SHA-256 hashes.
• Customer identifiers are never stored in plaintext. They are hashed in memory the moment an order arrives. A check in our build fails if the database gains a column that could hold a shopper's plaintext email, phone, name or address.
• Store isolation: every database query and every delete is limited to one merchant's workspace (one shop, in the Shopify app).
• Authenticity: order webhooks are HMAC-verified and Stripe messages are signature-verified before anything is written.
• Abuse limits on sign-in, event intake and the free scanner, and browser security headers on every page.

No system is perfectly secure. If a breach affects a merchant's data we will notify that merchant within 24 hours of becoming aware of it, in time for them to meet their own 72-hour obligation as controller.

16. Sub-processors

Other third parties. Our pages load fonts from Google Fonts, so your browser contacts Google, which sees your network address as with any web request; we send Google nothing else. Klaviyo is used only for our marketing website's waitlist (section 19). It never receives app data or shopper data.

We will give merchants notice before adding or replacing a sub-processor.

17. International transfers

We are US-hosted. Personal data from the EU, UK and Switzerland is transferred to the United States. Where required, transfers are covered by the EU Standard Contractual Clauses (processor-to-processor module) and the UK Addendum, incorporated into our Data Processing Agreement, which is available on request.

18. Your rights, and how a request reaches us

18.1 If you are a shopper

Contact the store you bought from. They are the controller, and they act on your request through Dave:

• Web app. The merchant finds you on their Privacy screen by order ID, email, phone or customer ID. Delete erases your storefront events from the browsers linked to your orders, the forwarding records holding your hashes, your stitched identity and any pending export — in that store only. Export puts what we hold about you into a file the merchant can download.
• Shopify app. When the merchant raises your request through Shopify, Shopify sends it to us automatically. customers/data_request: we assemble your storefront events and forwarding records into a file the merchant downloads from the app's Privacy screen, and remind them in-app until they do. customers/redact: a real deletion — we match Shopify's named orders to the purchases we recorded, read the visitor ID from each, and erase every storefront event from those browsers, the _fbp/_fbc values with them, the forwarding records holding your hashes, any pending export, and your stitched identity. shop/redact, sent 48 hours after uninstall: we erase the store's credentials, scores, event history, stitched identities, delivery health, onboarding record and Shopify session. Only a shop domain and a timestamp survive, as proof the deletion happened.

What a deletion cannot reach, stated plainly: a purchase we never recorded (nothing ties it to the request), and anything Meta has already accepted, including hashes already in a merchant's audience. That is undone through Meta's own controls and the merchant's ad account, not ours.

18.2 Merchants, Facebook users and scanner users

• Merchants: Settings lets you export what we hold about your store as a file (without your credentials, which never leave the server) and delete your workspace on the spot. You can also email us.
• Facebook users: see section 10.
• Scanner users: email us with the report link and we will delete the scan.

18.3 The law

GDPR / UK GDPR gives access, rectification, erasure, restriction, portability, objection, and the right to complain to a supervisory authority. CCPA / CPRA gives the right to know, delete, correct, and opt out of sale or sharing.

We do not sell personal information, and we do not share it for cross-context behavioural advertising on our own behalf. A shopper's opt-out of sale or sharing, including Global Privacy Control, stops Dave sending their data to Meta for the merchant (section 11.4). We send events and audiences to Meta on the merchant's instruction, for the merchant's own ad account, as the merchant's service provider.

19. Our marketing website

If you join the waitlist on our marketing website, we collect your email address and store it in Klaviyo so we can email you about the launch. Legal basis: consent. Unsubscribe from any email, or email david@un8brands.com, and we will delete you from the list.

Waitlist data is completely separate from the app. It is never mixed with merchant or shopper data, and app data is never sent to Klaviyo. The marketing website sets no advertising or analytics cookies of its own.

To count visits to our public marketing pages we use Cloudflare Web Analytics. It sets no cookies and does not track you across sites; it records page views and basic, non-identifying details such as the page, referrer, browser type and country. It runs only on the marketing pages, never inside the app.

20. Children

Dave is a business tool for merchants and is not directed at children. We do not knowingly process data about anyone under 16. If you believe we have, email us and we will delete it.

21. Changes

We will update this page when Dave changes. Material changes affecting merchants will be notified by email or in-app before they take effect. The "last updated" date at the top always reflects the current version. Our Terms of service explain the rest of our agreement with merchants.

22. Contact