Privacy Policy

As a controller — for our own site visitors and account holders (merchant users), we decide how and why we process that data (e.g. account, billing, support, security).

As a processor — when the Service reads and replies to a merchant’s direct messages, we process end-customers’ message content and identifiers on the merchant’s instructions. The merchant is the controller of that data; our processing is governed by our Data Processing Agreement. If you are an end-customer with a request about your data, please contact the merchant you messaged; we will assist them as their processor.

Merchant account data (we are controller)

• Identity & contact: name, email, password hash.
• Workspace & connection data: connected Instagram/WhatsApp/TikTok and Shopify accounts, access tokens (encrypted at rest), catalog and knowledge you ingest.
• Billing: plan, subscription status, and payment metadata (card data is handled by Stripe — we never store it).
• If you cancel a paid plan, we may email you once, about 30 days after it ends, with an offer to come back. You can opt out on the cancel screen or with the unsubscribe link in that email. We send it on the basis of our existing customer relationship (soft opt-in).
• Usage & device: log data, IP address, pages viewed, and cookies (see §7).

End-customer data (we are processor for the merchant)

• Message content sent to/from the merchant’s connected channels.
• Platform-provided identifiers (e.g. the sender’s platform-scoped ID, username, profile image) and consent/opt-out state.
• Taps on a merchant’s tracked links. When someone taps a link a merchant sent through the Service, we record the tap and its approximate location — country, region and city — as our hosting provider estimates it from the request. We do not store the IP address, precise coordinates or a postcode. The merchant sees these locations as totals by country and city. A link preview (an app fetching the link to draw its preview) is counted as a tap but gets no location.
• Comments on a merchant’s Instagram posts. For each comment someone leaves on a merchant’s posts, we record which post, the comment’s ID, the commenter’s platform-scoped ID, which of the merchant’s automations or flows matched it (if one did), and when — not the words of the comment. The merchant sees comment totals per post and who comments most; someone who isn’t one of the merchant’s contacts is never shown by ID. These records are kept for 13 months, are included in the person’s data export, and are deleted when their data is erased.
• Voice messages. If an end-customer sends a voice message, we retrieve the audio and convert it to text so the merchant’s agent can understand and answer it. The audio itself is never stored: it is transcribed in memory and discarded in the same operation, and only the resulting text is retained — as part of the conversation record, on the same terms and for the same retention period as any typed message. We do not perform voice or biometric identification, and we do not use voice data to train any model.
• Email addresses, if the merchant sends email campaigns. An address a person gives the merchant — in a conversation, in a file the merchant imports, or to a member of the merchant’s team — kept as its own record and linked to the person it came from; the record of whether and how they agreed to receive email (where, when, and the words they were shown); and what happened to each email sent to it (sent, delivered, bounced, marked as spam, unsubscribed, a link clicked). We do not record whether an email was opened. When someone unsubscribes, an address bounces or an email is marked as spam, we keep a one-way hash of the address and the reason — not the address — so they are not emailed again, even after the merchant erases their record.

Site visitors who contact us or join an updates list (we are controller)

• Contact form: your email, optional name, topic and message, saved and, when enabled, emailed to our team through Resend so we can reply.
• Updates lists (availability updates and the playbook list): your email, which lists you asked for, when, and the form wording you agreed to; leave one list or all at /unsubscribe, and we keep a removal record so you aren’t added back.
• Calculator breakdowns: the address you entered, the tool, and the one email you asked for; this is not a subscription.

Partners in our partner program (we are controller)

• If you apply to be a partner: your name or brand, handle, the link to where you post, anything you tell us about your audience, and when you accepted the partner terms.
• To pay you: your payout method (PayPal or Wise) and that account’s email address, plus a record of every commission and payout. A commission record holds amounts and dates; it doesn’t show you who the customer you referred is. We use the customer’s billing details only to check you aren’t referring yourself.
• Before we pay you: your legal name, the country you pay tax in and, in Australia, your ABN (elsewhere, your own tax number if you give one). Only the last three characters of the number are ever shown back to you.
• Payout records and tax details are kept for accounting and tax even if you leave the program or delete your workspace.

Media the merchant uploads

• Voice recordings, video and documents a merchant creates or uploads to send in their own automations. These are the merchant’s own content, stored in their workspace until they delete them, and are transcribed for search and accessibility.

• Provide the Service (contract): operate accounts, connect channels, generate and send replies, show your inbox and analytics.
• Billing (contract): manage subscriptions and payments.
• Security, fraud prevention, and compliance (legitimate interests / legal obligation): rate-limiting, abuse prevention, honoring messaging-window and consent rules.
• Support and communication (legitimate interests / contract).
• Product improvement (legitimate interests): we do not use end-customer DM content to train third-party foundation models; DM content is sent to our AI sub-processor only to generate that conversation’s reply.
• Speech-to-text (contract): a voice message sent to a merchant is transcribed so their agent can read and answer it — the same purpose a typed message serves. Audio is discarded once transcribed and is never used for training or for voice identification.

We share data with the vendors below strictly to run the Service. Each is bound by a data-processing agreement. A current list is maintained in our DPA.

Customer email is not sent through our Resend account. A merchant who sends email campaigns connects their own email-provider account (today, Resend) with their own API key. That provider is the merchant’s processor, under the merchant’s own agreement with it — not our sub-processor. On the merchant’s instruction we transmit each recipient’s address, the email with its personalised values, the merchant’s sender details and an unsubscribe link to that account, and receive its delivery reports back.

HyperDM is Australian-owned. Its application hosting and primary database are in the United States. Australian ownership does not mean Australian data residency. Other subprocessors may process data in additional locations, as listed below. We are based in Victoria, Australia. Where we transfer personal data out of the UK/EEA, we rely on appropriate safeguards — the UK International Data Transfer Agreement / Addendum and the EU Standard Contractual Clauses — a copy of which is available on request.

Merchant account data is kept while your account is active and for a limited period afterward to meet legal, tax, and security obligations. End-customer DM data is retained for the merchant per their settings and our DPA; on account deletion or a valid erasure instruction, we delete or de-identify the associated data within a commercially reasonable period, except where retention is legally required. If a merchant sends email, the one-way hash of an address that unsubscribed, bounced or reported spam is kept, with its reason, for as long as the merchant’s workspace exists — also after the person’s record is erased — so they are never emailed again. It is deleted with the workspace. Records of comments on a merchant’s Instagram posts (which post, the comment’s and the commenter’s IDs, the automation or flow that matched and when — never the text) are deleted 13 months after they were recorded.

Strictly-necessary cookies (no choice involved)

We use strictly-necessary cookies to run the site — your sign-in session, your light/dark theme preference, a record of the analytics choice you make below, and a two-letter note of which consent rules apply to you (worked out from the country your connection comes from, at our edge network, and holding no identifier of any kind). These are first-party and cannot be switched off without breaking the Service or the choice mechanism itself.

How we ask, and why it depends on where you are

The two tools below both store an identifier in your browser and share data about your use of this site with a third party. We ask about them in one of two ways:

• If you are in the EU/EEA, the UK or Switzerland — opt-in. Nothing under the next two headings runs until you choose Allow. Until then the PostHog script and the Meta Pixel are not downloaded and not executed, no advertising or analytics cookie is set, and nothing about your visit is sent to either company. Declining is one click, is remembered, and we do not ask again.
• Everywhere else — opt-out. The two tools run when you arrive, a notice tells you so, and Opt out stops them at once and is remembered: analytics and session recording stop, the Meta Pixel is told to send nothing further and its two cookies are removed. Scripts already downloaded cannot be unloaded until the next page, and neither company receives anything more.

We honour Do Not Track and Global Privacy Control everywhere. If your browser sends either signal we never ask, never load either tool, and never send anything. You can change your mind at any time: clear this site’s data in your browser and the notice returns, or contact us at hello@hyperdm.app and we will exclude you.

Product analytics (PostHog)

Subject to the choice above, we use PostHog — a third-party product-analytics provider — to understand how people move through our site and app, so we can find the steps where people get stuck. We are specific about it:

• What it records: pages viewed, clicks, and the milestones you reach (for example: signed up, connected a channel, created an automation), plus your device type, browser, approximate location from your IP, and a random ID stored on your device. When you create an account, that random ID is linked to your account’s own random identifier — never to your email address or name — so we can see the path from a first visit to a signup.
• Session replays. Subject to the same choice, PostHog records a reconstruction of your screen on our public site and on the screens where you set up your own account, so we can watch where a flow breaks down. Everything you type is masked — passwords, forms and message boxes are never recorded.

What PostHog never receives

Your customers’ direct messages are never sent to PostHog. On every screen that displays end-customer content or identity — your inbox, contacts, activity, broadcasts, sequences, segments and dashboard — session replay is switched off automatically and on-screen text is masked before any event is sent. Explicit events use an allowlist of properties. We also strip email addresses, record identifiers and authentication tokens out of page addresses before they leave your browser. As a merchant’s processor we do not use their end-customers’ data for our own purposes, and product analytics would be exactly that.

Advertising measurement in your browser (the Meta Pixel)

Subject to the same choice, our pages load Meta’s pixel — a script from Meta (Facebook and Instagram) that tells Meta which of our adverts lead to real signups. It sets two cookies on hyperdm.app: _fbp, a random browser identifier (kept for 90 days), and _fbc, the click identifier from a Meta advert link you followed, if you followed one (also 90 days). It reports to Meta the pages you view on this site and two signup milestones — the signup form submitted or a sign-in provider chosen, and an account created — each with a random event number. It does not send anything you type, and we have switched off Meta’s “automatic” collection of button text and form fields. Our server sends a second copy of the same two milestones; the next section says exactly what that copy contains and why there are two.

Site traffic counts (no cookies, no consent needed)

Regardless of the choice above, we use Ahrefs Web Analytics to count visits to our public website and see which pages are read and where visitors arrive from (for example, a search engine or a link in a post). We use it to understand which of our articles are found and read. It is built to work without identifying anyone: it sets no cookie and stores nothing on your device, keeps no identifier for you, and records only the page address, the referring site, and your browser type, device type and country. It cannot recognise you across visits and it never sees anything you type. We rely on our legitimate interest in knowing how our website is used; because nothing is stored on your device, no consent is asked for. You can object at any time by contacting us at hello@hyperdm.app.

Our own signup funnel

Subject to the same analytics choice above, we measure our own signup funnel so we can see where people abandon the form. This part is first-party and self-hosted — it goes to our own database. It records which step was reached and when, identified by a random id held in your browser’s session storage (not a cookie) that is discarded when you close the tab. It never includes your email address, your IP address, your browser details, or anything you type. Both the browser and our receiving endpoint respect your analytics choice, Do Not Track and Global Privacy Control. Email and provider signups have distinct method labels so we can compare the same step across signup paths.

We advertise HyperDM, and we need to know which adverts bring people who go on to actually use the product — otherwise we are spending money blind. So when you arrive from one of our adverts and then submit the signup form, create an account, connect a channel, or send your first automated reply, we report that milestone to the advertising platform the advert ran on. Today that is Meta (Facebook and Instagram) only.

Two copies, counted once. The first two milestones are reported twice: once by the Meta Pixel in your browser (previous section) and once by our server. Both carry the same random event number, and Meta uses it to count the milestone once. Browser reports are often lost to ad blockers and browser privacy features; the server copy is what makes the count reliable. The last two milestones are reported by our server only, once an hour, from account records we already hold.

What our server sends, in full:

• which milestone happened, when, and its random event number;
• a hashed form of your email address — a one-way SHA-256 digest, so the platform can recognise an account it already knows and cannot read your address out of it;
• the advert-click identifier: the pixel’s _fbc cookie when the pixel is running, otherwise the identifier that was in the link you followed, held for that browser tab only;
• the browser identifier: the pixel’s _fbp cookie when the pixel is running, otherwise a random identifier we generate ourselves and keep in your browser’s local storage so the platform can tell a returning browser from a new one. Either way it holds nothing about you, and it persists between visits until you clear this site’s data;
• your IP address and your browser’s user-agent string (the browser and operating system it reports), as your browser sent them when you signed up;
• the address of the page the signup happened on.

We do not send your name, your password, your message content, your customers’ data, or anything you type into the product. We do not build or keep a separate advertising profile: each milestone is reported once, and that is the end of it.

Your choice covers the server too. Where consent is required, none of this — pixel or server report — happens unless you chose Allow; elsewhere it happens unless you opted out. Your browser passes your choice to our server at the moment you sign up, and the server sends nothing when the answer is no.

Our lawful basis is your consent where the law requires it, and otherwise our legitimate interest in measuring the effectiveness of our own advertising. You can object or withdraw at any time — see “Your rights” below — and we will exclude your account from this reporting.

This is separate from the advertising measurement described in the previous section, which is about HyperDM’s own adverts and our own account holders. A merchant using the Service can choose to report conversions from their own business — a lead captured by one of their automations or their AI agent, a payment through one of their payment links, a Shopify order, a Hotmart purchase, or a step in one of their flows — to their own Meta dataset, through Meta’s Conversions API. This happens only when that merchant connects their own Meta dataset and switches events on: they connect it with an access token they create in Meta, confirm who may be reported, send a test event, and switch each kind of event on. Nothing is reported for a merchant who has not done so, and nothing that happened before an event was switched on is sent — what counts is when the conversion happened, not when we learn of it.

For this reporting the merchant is the controller and the advertiser: they decide which events are reported and about whom, the data goes into their own dataset under their own agreement with Meta, and they are responsible for having a lawful basis and any consent it requires. We act as their processor, on their instructions (see our Data Processing Agreement). The merchant chooses either to report only the people whose yes/no field in the Service says yes, or — as the workspace owner’s own confirmation that the business has a lawful basis — every contact. Someone who unsubscribed, or whose contact record was merged into another, is never reported under either rule, and this is checked again just before each event is sent.

What each reported event contains, in full:

• the kind of event (a lead, a purchase, or one of the standard events a flow step names) and when it happened;
• a reference we generate from our own record of the conversion, which stays the same if it is sent again;
• whether it is tied to a conversation in the Service (it happened in a conversation, or came from a link sent in one) or not;
• a hashed email address and/or phone number — a one-way SHA-256 digest of one the merchant already holds for that person in the Service, for example one the person typed in a conversation — and a hashed reference to their contact record. If neither an email address nor a phone number is known, nothing is sent;
• for a purchase, its order value, currency and order ID;
• if the merchant switched on Meta’s Limited Data Use, that setting and the US state they chose.

A purchase is reported for one person, and it is that person’s hashed details that are sent with it. For a Shopify order that came from a checkout link sent in a conversation, that is the person it was sent to; for a Hotmart purchase, the one contact whose email address or phone number matches the buyer’s (for a Hotmart subscription, only its first payment is reported, never a renewal). Otherwise — a payment through one of the merchant’s payment links, or another Shopify order — it is the person whose link to that product, sent to them in one of the merchant’s conversations, was opened in the 7 days before the payment — whoever opened it — and only if no other product link we sent for it was opened in that time, whether it was sent to someone else or can’t be tied to anyone. Openings of a payment link shared any other way — posted elsewhere, or added to another message — are not taken into account. That is a best guess, not a record of who paid: it can be someone other than the buyer. A purchase no one can be picked for is not sent.

We never include message content, names, usernames, the products bought, an IP address or browser details. Our own record of each delivery keeps which kinds of identifier were sent — never the email address, the phone number or their hashed form — and when a contact is erased, that record stays without any link to them. The only personal detail in a test event a merchant sends to check their setup is the hashed email address of the team member who sent it.

A merchant can stop at any time by switching an event off, or by disconnecting, which deletes the access token we stored and stops every event still waiting to be sent (one already on its way to Meta may still arrive). If you are one of a merchant’s customers and have a question about this reporting, contact that merchant; we will assist them as their processor.

Advert referral ids. Where we have turned this feature on for a merchant’s workspace — whether or not the merchant has connected a dataset — the first time someone reaches that merchant from a Meta click-to-message advert, we keep the ids Meta sends with it on that person’s contact record: the advert id, Meta’s label for where it came from and, for WhatsApp, the click id. Never the advert’s text. The merchant sees them in their contacts like any other contact detail, and they are deleted when the contact is erased. Conversion reporting does not send them to Meta.

Depending on where you live, you may have rights to access, correct, delete, port, or restrict your personal data, to object to certain processing, and to withdraw consent. California residents may request access/deletion and to opt out of “sale”/“sharing” — we do not sell personal data. To exercise rights over data we control, contact us at hello@hyperdm.app. You may also complain to your local supervisory authority. For DM data a merchant controls, contact that merchant.

We apply technical and organizational measures including encryption in transit, encryption of stored channel access tokens, strict tenant isolation (row-level security), signed-webhook verification, and least-privilege access. No method of transmission or storage is perfectly secure.

The Service is not directed to children under 16, and we do not knowingly collect their data.

We may update this policy; we will post the new effective date here and, for material changes, notify account holders. Questions or requests: Anthony Casauria (sole trader), St Helena, Victoria 3088 (full registered address available on request), Victoria, Australia — hello@hyperdm.app.