Skip to content
Hazelsong is still being built.Skip to content
Hazelsong

Legal · Last updated October 2026

Privacy Policy

Publication choices and removal requests

The email-confirmation, permission-withdrawal, and content-notice pages do not load page-view analytics. They send no referrer and are not publicly cached or indexed.

The business decides why it collects and publishes its customers’ testimonials. Hazelsong processes those testimonials to provide the service and separately manages account security and content notices. Applicable privacy roles depend on the processing activity and agreement; hosting does not remove either party’s legal obligations.

Permission for the business’s own website is separate from permission for public testimonial pages hosted by Hazelsong. Publication choices start unchecked. Public hosting is optional and pages may be read by anyone once the owner publishes them. Consent records include the statement, selected uses, and time of submission.

Authors submitting through the collection form receive a private withdrawal link after sending. Only its hash is stored with the testimonial. Withdrawal stops publication through Hazelsong; the original permission record is retained with the business’s records unless deleted. Copies previously downloaded or posted outside Hazelsong require a separate request. Authors can request withdrawal, deletion, or other applicable privacy rights at the content notice form without an account.

Project email confirmation uses a hashed, single-use token that expires after 15 minutes. Confirmation replaces the dashboard link and records its time. Content notices contain the contact email, content URL, explanation, and reference; they are sent to our support mailbox, used to investigate and respond, and retained only as needed for the request and applicable legal obligations. Access is restricted to staff handling the request; unnecessary data should not be submitted.

Hazelsong is operated by Vinicius Colares Sucupira, an individual trading as Solrenning ("we", "us"). For our own purposes — your account, billing, security, content notices, the affiliate program and this site's own counters — we are the controller of the personal data described here. For the testimonials and everything else a business collects through Hazelsong, the business is the controller, and we process it on its behalf under our Data Processing Addendum; “Who decides, and the legal basis for each use” below says which is which. This policy explains what Hazelsong stores and why, for both project owners and the people who submit testimonials through a Hazelsong collection form.

Project owners

We store the email address, project name and website you provide when creating a project, and your subscription status if you upgrade — with the extras and monthly packs on it and its current billing period, as Paddle reports them, because those decide what your account may use. If you add a monthly pack, we also keep when you asked for it to start at once and acknowledged that its charge is not refundable once any of it is used, in the words you were shown, and any refund or chargeback of a pack that Paddle reports to us, because those decide whether a pack can be refunded and whether it still counts. Billing details (card, address) are collected and processed directly by Paddle.com, our merchant of record — Hazelsong never sees or stores your card number.

Before you pay, we ask for your business's country, name, a tax or VAT number (required in the European Union and where your country requires one, optional elsewhere) and, in the United States and Canada, its ZIP or postal code, and you confirm that you buy for your business. For an EU VAT number, our server sends the country code and the number to the European Commission's VIES service, which says whether it is valid; nothing else about you is sent to it, and we keep only its answer's date (and its consultation number when it gives one), not the name or address it may return. With your subscription we keep the sentence you confirmed, its version, the time, your country, your VAT number and VIES's date; the business name, country, postal code and tax number also go to Paddle, for the invoice and the tax on it. They are deleted with your account.

When you subscribe, Paddle is told two things about the project the subscription is for: its public address — the same one your collection form and your wall already answer on — and a reference our server makes for the person who pays for it, holding the project's internal number, a date it expires and a code only Hazelsong can produce. That reference is what comes back to us when the payment completes, and it is how the plan reaches the right project; it opens nothing. Your dashboard link is not part of it. That link is the whole of logging in, and a payment record kept by another company is no place for it.

Once you have paid, the Manage billing button in your dashboard asks Paddle for its billing page for your account, where you can change your card, download invoices or cancel. Paddle is sent nothing new to do it: only your Paddle customer id and subscription id, which Paddle gave us when you subscribed. The address Paddle answers with signs you in to that page, so it goes to your browser and nowhere else; we do not store it, log it or email it. To keep a link in the wrong hands from pressing it over and over, we count your account's presses in each hour and keep that count for two hours. If you have paid and open the payment page from your dashboard, Paddle's script on that page is told your Paddle customer id, which Paddle already holds, so that Paddle can show you its own notices about a payment that did not go through and its own steps when you cancel. Nothing else is passed to it, and for anyone who has not paid, not even that.

Paddle's script is loaded on two pages of this site and on no other: the payment page, and /billing/update, the page a message about a payment for your plan that did not go through brings you to. On that second page we pass it nothing about you; it is there so that Paddle Retain, the part of Paddle that recovers failed payments, can open Paddle's own window to update your card from the link in that message. Retain's emails about it are sent by Paddle, from Hazelsong's address, through Paddle's own email provider.

If you list the sites your widget may appear on, we keep that list with your project. When your widget cannot draw on one of your pages, we keep, for fourteen days after the last time it happened, that page's host and path, which of four things went wrong, when it was last seen and how many times, so the report can show you the page and the fix; and for two days, a note that the page already reported that day. Both go when you delete the project.

If you record a short video to go with your requests for testimonials, we keep the recording in our storage under your project, like any recording a customer sends you; the random key that the link to it carries, so that your project's public address alone opens neither the page nor the file; and when it was recorded. The page that plays it shows your business's name and the recording, and nothing about the person who opened it. Each play is counted toward your account's month of video and pictures shown, as every recording on a public page is; your own preview in the dashboard is not. Replacing the recording keeps the key, so links already sent play the new one; removing it deletes the file and the key, and the links open nothing. It goes when you delete the project.

When we look at your account

There is no password. You log in with a one-time link sent to your address, and your dashboard's own link works as a bookmark until you replace it. That means two things, and both are said here rather than left to be discovered. If you lose access to that address, we can still help you: write us and we will check that the project is yours. And because we can do that, we can also open your dashboard ourselves. We do it to answer a request you made, to investigate a fault you reported, or where the law requires it — not otherwise, and never to read your testimonials for our own purposes. Nobody outside Hazelsong is given that access, and deleting your project removes the link along with everything else.

Connecting an assistant

If you connect an assistant such as Claude or ChatGPT to a project by logging in rather than pasting a key, we store, for that connection: the name the assistant gave itself and the addresses it asked for its answer to be sent to; the project you chose and what you allowed it to do; a one-way fingerprint of your email address, not the address, so that it stops working if you no longer hold the project; when you connected it and when it was last used; and one-way fingerprints of its current tokens, never the tokens themselves. While you are logging in, your address is kept with the request for at most thirty minutes, and the browser that asked for the login link holds one cookie with a random value for fifteen minutes, sent only to the page that completes the login, so that the link works in that browser and nowhere else; it names nobody and is not read for anything else. The connection expires on its own sixty days after the assistant last renewed it; you can disconnect it at any time on the API page of your dashboard, and deleting the project removes it. An assistant that registered with us but was never connected is forgotten after thirty days. What a connected assistant reads is only what your API key could read: testimonials whose writer agreed to a website, and, if you checked “Read your report's figures”, the counted figures a client share link shows — how often your wall was shown, the lift test's counts and the forms' steps, with no words, names or addresses in them.

Calls from your API keys and connected assistants are counted per account and per month — a number, kept seventy days, with nothing about what was asked — so that the month's allowance on your plan can be kept. A key records when it was last used, at most once a minute. When the month is used up, the key or connection that was refused is marked for at most an hour, so that its next request is refused without anything else being read.

The same is true of the views, plays and clicks your walls and widgets report, the steps your collection forms report, and of testimonials arriving through your collection pages: each is a number per account and per month, kept seventy days, with nothing about the reader or the writer in it. When the month's counted events are used up, a mark saying so is kept for forty days, so your walls and widgets can stop reporting until the month turns. To serve readers without reading our database on every view, a copy of what your walls and widgets show — the testimonials you published with permission for a website, your project's name, mark and list of sites, never your address, your dashboard link or a writer's address — is kept by our host's cache, thrown away the moment you change anything and rebuilt at least once a day. We also keep a list of which of your testimonials are published, and their ratings, to build that copy from; it goes with the project.

The same views, plays and clicks are also counted per day, so your report can draw last month and this one a bar a day: a number per widget or wall and per day for views, and per day for the rest, with nothing about the reader in it, each month kept ninety days from its first count. When your wall was last shown is read from those days.

Notes on that chart are kept with the project: the day, the words, who wrote them (you, your API key, or Hazelsong itself when something happened) and when. A note sent through the API with an idempotency key keeps a one-way fingerprint of that key, so a retry is recognized; the key itself is not kept. A project keeps its 200 latest notes; deleting a note removes it, and deleting the project removes them all. The notes Hazelsong writes say only what happened in the project — how many people a pasted list was sent to, a lift test started or stopped, asking after a purchase switched on, a store connection made, a button added to a wall with its words and the wall's name — never a person's name or address.

Deleting everything

There is a button in your dashboard that removes the project and everything in it: every testimonial, every video and photograph your customers recorded, the forms, the walls, the keys, the connected assistants, the seats and the address it answered on. The recordings are deleted from storage, not hidden. It cannot be undone, by you or by us, and it does not cancel your subscription — that is held by Paddle, and you cancel it from Manage billing on your dashboard's People and projects page, or from the link on any Paddle receipt.

Handing a project to somebody else

The owner of a project can hand it to another person by typing that person's email address. We use the address once, to send that person a link, and keep it with a one-way fingerprint of the link, the project, the owner's address and the time for at most 72 hours, or until the link is used, canceled or replaced, whichever comes first. The link itself is not kept. The person who opens it is shown the address the project was made with, the project's name, how many testimonials, forms and walls it holds, the names and roles of its seats, and the host and last four characters of each webhook endpoint and channel — never a testimonial's words, never anybody's email address but the two in the transfer, and never a dashboard link. If they accept, the project, everything in it and its seats become theirs, and one email goes to each of the two people saying so; if they say no, one email goes to the owner. Neither carries a link that opens the dashboard. The project's API keys, connected assistants and client share links are removed at that moment, and the owner's own address is taken off its list of addresses for summaries and alerts. Subscriptions are not moved: each person's stays theirs.

All your projects on one page

The owner of several projects can see them on one page: for each, how many testimonials wait in Pending, how many arrived this month, how often its wall was shown this month and how many things its health check lists. These are counted from what each project already keeps, and each project's four numbers are kept for five minutes so that reopening the page does not count them again; nothing else is stored. If the owner chooses one summary email for several projects, we keep which projects, how often, and up to five addresses to send it to, on the owner's own record, until they change it; a project deleted or handed to somebody else leaves it at once.

Sharing your figures with a client

An owner or an administrator can make a read-only link to a project's counted figures for somebody outside their team. For each link we keep the label they gave it, when it was made, the day it stops working if they set one, when it was last opened, and — if they set a password — the password as a slow, salted one-way hash that cannot be turned back into the password. The address itself is not kept: only a one-way fingerprint of it, so it is shown to the owner once and cannot be shown again. Wrong passwords are counted for an hour, against the link and not against the person trying. When the right password is given, that browser keeps a cookie for twelve hours, signed for that link and sent only to that link's page, saying it was unlocked; it holds nothing else.

A person given a link sees counted figures only: how often the wall was shown, played and followed, by month, by widget or wall and by the site and campaign readers came from; how many people opened, started and sent the collection forms, and opened a review site afterward; and the lift test's groups and verdict. If the owner checks “Show notes on shared links”, which is off until they do, the notes on the report's chart for last month and this one are shown too, as they were written. Never a testimonial's words, never the name or the email address of anybody who wrote one, never what the risk reading found, never the dashboard link. Nothing about the person opening the link is recorded beyond the time it was last opened. Revoking a link removes it at once; deleting the project removes every link it had.

On Pro, an owner or an administrator can set “Prepared by” for a project: a name, a mark, a color and an email address a client may write to. We keep the four on the project's own record, and the mark as one image file in the project's storage, at the size it was sent, counted against the plan's storage. They are shown only where the owner checks them: on a share link, above the figures and only after its password if it has one, where the mark is fetched through our own address so that each showing is counted toward the account's delivery, as every picture is; and in a summary email, where the name and the address are written as text. The mark is never put in an email, because an image fetched when a message is opened would tell us that it was opened, and the address is never set as the email's reply-to. Removing it takes the four off the record at once, and the file is deleted by the regular clean-up of files nothing points at, no sooner than a day later; handing the project to somebody else takes it off the same way; deleting the project deletes all of it with the project.

The help assistant in the dashboard

The Help button in the dashboard answers questions about Hazelsong from this site's own pages. To answer one, Anthropic is sent the question, up to three earlier questions and answers of the same conversation, and the parts of our public pages chosen for it. Nothing of the project is sent unless the person asking presses Allow for that question; then Anthropic is also sent the lines the report lists under “Is anything broken?” and how much of each monthly allowance is used, with anything shaped like an email address taken out first. Never a testimonial's words, never anybody's name or email address, never the dashboard link. We store none of the conversation: it is kept in that browser tab, and gone when the tab closes. The one exception is “Send this to a person”, which emails the conversation, anything the person adds, the project's name and public address, and the asker's own address to reply to, to our support mailbox, where it is kept like any other email to us. We count how many an account sends in a month, and nothing else about them.

Notices about a project, by email or in a channel

An owner can ask to be told when a testimonial arrives, and can have the project's summary, alerts and those notices posted to one Slack, Discord or Microsoft Teams channel. For the channel we store the webhook address the owner pasted, as a secret — the dashboard shows only its host and last four characters — with the last ten posts (when, what kind, and what the channel answered) for thirty days. While a notice waits for its hour we keep, for at most three days, the first name the writer gave, the stars, the 0-to-10 score, which kinds of thing the risk reading flagged, whether there is a video, and when it arrived. That is all a notice says about a testimonial: never its words, never the writer's email address, never what the reading quoted, and never a link that opens the dashboard. It goes to the addresses the owner set, and to Slack, Discord or Microsoft, whichever the owner chose, where that company's own terms and the owner's workspace decide how long it is kept. Removing the channel, or deleting the project, removes the address and its log at once.

When an owner starts a lift test with a planned end — a date, or a number of readers in each group — we keep that plan with the test, and when it is reached one email goes to the owner's own address with the test's counted figures and its verdict. Nothing about any reader is added to it, and it carries no link that opens the dashboard.

Testimonial submitters

When someone submits a testimonial, we store what they gave the form, on behalf of the project owner who collected it: their name, and their role and company where they filled them in; their email address, where the form asked for it; the words themselves; an optional star rating; a photograph of themselves, a picture attached to the testimonial, and a video — either a recording or a file they uploaded, held in our storage, or a link to a video on another platform — or, instead of a video, a recording of their voice alone, made with the microphone and never the camera, held in our storage exactly as a recorded video is, played on public pages only through the same counted door, and deleted with the testimonial. We also store the exact permission sentence they agreed to, which places they allowed it to be shown, and the date and time they agreed; a fingerprint of that version (a SHA-256 of the words as sent, the sentence, the places, the reward disclosure and the business's release version, which holds nothing readable and is printed on the testimonial's public record unless a part of the words was removed); whether it came through a personal request link we emailed, and whether that request was made by an order the business reported — never the address itself on a public page; the answers to any extra questions the owner's form asked; and, where the owner's plan includes them, a transcript of the recording and translations of the text, both kept alongside the original rather than replacing it. Under a voice recording, which has no picture, the transcript is also offered to readers of the business's wall and widget once the testimonial is published there, labeled as a machine's reading; a video's transcript stays with the business. Where the business's form is an interview — several of its own questions, each answered by typing or by a short recording — we store each question as it was asked and each answer as given: a typed answer with the rest of the words, and a recorded answer, of the voice alone or a video, held in our storage exactly as any recording is, played on public pages only through the same counted door, and deleted with the testimonial. One permission covers the whole interview. Where somebody on the business's team has a recorded answer written down, the transcript is kept on that answer and offered to readers beside it once the interview is published, labeled as a machine's reading. Where the business's form carries a release of its own — a paragraph the business wrote, which you checked as well as our permission — we store its exact words as you checked them, which version of it they were, and the time you agreed; it is shown to the business, included in its export, and printed on the testimonial's public record once the testimonial is published. Where an email address was given, we also store whether its domain is a throwaway-mail service or the project owner's own business domain — worked out by a fixed rule, with nothing sent anywhere — and show that only to the project owner, never publicly. When it is the business's own domain, the testimonial is not published until the business confirms you are a customer and not on its team, and we keep that it did, when, and who, for the business only. When the risk reading finds that a testimonial states a result, the business adds, in its own words, what results customers can generally expect; that line is published with the testimonial, labeled as the business's. Each testimonial also keeps its history, with the testimonial and for as long as it is kept: how it arrived, whether it was read for risk, and each time the owner's team proposed, approved, signed, rejected or took it down, removed a part, added a video or sent a thank-you, with the time and the name the owner gave the teammate who did it. The history is shown only to the project's team and written to the owner's export, never publicly; the testimonial's public record says only whether a second person reviewed it, with no name. When the team rejects a testimonial or takes it down, it records why, from a fixed list and sometimes with a short note of its own; that reason is kept with the testimonial and its history, seen by the team and in the export, and never shown publicly or to you. If you use your private withdrawal link to ask the business to reconsider, we keep the time and the message you wrote with the testimonial for the team to read, and send that message to the business in one email; your address is not added to it. While a testimonial waits for a decision, the team may give it to one of its members: we keep which member and when, with the testimonial, shown only to the team and in its history, never publicly. Its place in the team's queue and its deadline are worked out from what the testimonial already holds, and its language is guessed from its words by a fixed rule, with nothing sent anywhere and nothing more stored. To notice the same words arriving twice, we also keep, for each project, a fingerprint of each testimonial's words — a one-way hash of the text with case, punctuation and spacing taken out, from which the words cannot be read back — beside the testimonial's id. Both are deleted with the testimonial, and with the project. If the owner asked to be told when a testimonial arrives, a short notice goes to the addresses or the Slack, Discord or Teams channel they chose: your first name, your stars and score, the kinds of thing the risk reading flagged, whether it said you are owed a reply and of which kind (a problem, a loss or damage, or that you may leave), and whether there is a video — never your words or your email address. That reading also stores, for the project owner's eyes only, whether your words carry a detail of your own experience or are general; neither of these two notes is ever shown publicly. The project owner controls whether a submitted testimonial is approved and shown publicly, and is responsible for having the submitter's consent to publish it. If you submitted a testimonial and want it removed, contact the business you gave it to, or reach us directly and we will forward the request.

While you write on a collection form, what you have typed — your words, your name, role and company, your stars and score, and your answers to the business's own questions — is kept in your own browser, on your own device, so that closing the page does not lose it. It is stored only there, under this site's address; nothing of it is sent to us or to the business until you press Send, and it is deleted then. It is also deleted seven days after your last change, and the form has a button to clear it at once. Your email address, your photos, a video and your permission are never kept this way.

A business may set a screen up as a kiosk — a tablet at a stand or a front desk that many people use one after another. On a kiosk nothing of yours is kept on the device at all, not even the draft above: after you send, or press Start over, or leave a half-written form untouched for a few minutes, the form is emptied for the next person, permission included, and the thank-you screen offers no copy button and no link to your own accounts. The kiosk page makes a random number in its own memory when it opens and sends it with each testimonial, so we can hold one screen to a number of testimonials an hour; we keep only a count under a one-way code made from it, for an hour. It is not stored on the device, it is gone when the page closes, and it is not kept with your testimonial.

A business may also hand its form out on several labeled links — one printed on a receipt, one in an email signature — each the same page with a short label in its address. When you open, start or send the form from one of them we count that step under its label as well as under the form, as a number per month, and nothing else: no cookie, no identifier, nothing about you. The label is not kept with your testimonial.

If you wrote through a business's form and left your email address, the business may ask you once, through us, whether you would record a short video version of what you wrote. We then keep a record of that request — which testimonial it is for, and when it was made — and a one-way code made from the secret part of the link we sent you, not the link itself; the record is deleted when the link is used, when you choose "Not now", or after 30 days. If you record a video there and give your permission, we store the video with the testimonial, together with the exact permission sentence you agreed to for it and the time you agreed; your written words and the permission you gave for them are not changed. The video is shown nowhere until the business adds it to your testimonial; if the business discards it instead, the video is deleted.

If you wrote through a business's form and left your email address, the business may write back to you once, privately, through us. We send one plain-text email in the business's name, with the business owner's address to reply to, so your answer goes to them and not to us; we keep the owner's message and the time it was sent, with your testimonial, so the business can see what it said. It changes nothing about your testimonial, its permission or whether it is shown. Nothing is sent this way to an address our mail provider reported as undeliverable, or to anybody who marked a message from that business as spam.

Where the reading found what you wrote general, the business may also ask you one more question about it, once, through us. We keep the question, when it was asked, and — exactly as for a video request — a one-way code made from the secret part of the link, deleted when the link is used, when you choose "Not now", or after 30 days. If you answer and give your permission, we store your answer apart from what you wrote, with the exact permission sentence you agreed to and the time; it names the same places you allowed for your words and no others. Your answer is sent to Anthropic and read for risk, as a testimonial is, unless that month's readings are used up. It is shown nowhere until the business adds it, always under the question it answers, and the business can take it down again.

Visitors to this site

The home page asks one question — where your testimonials live today. Answering it adds one to a counter for that answer: no name, no cookie, and no way to tell one answer from another. One thing is done with your network address, and it is said here rather than left out: so that a script cannot drive those counters, the answer is counted against a one-way hash of it, which holds nothing readable and is dropped after an hour. A count of that kind — a one-way hash, a short window, a number — is also what stops a flood of sign-ups, of testimonials through a collection form, and of requests for a login link. Nothing else about you is kept in any of them. Not answering costs you nothing.

We do not use Vercel Web Analytics or another site-wide page-view tracking service on these pages, including hosted walls and collection forms at a project owner's own address. The product's aggregate form, testimonial and conversion counters are described below. Hosting and security services still process requests to deliver pages and protect the service.

A collection form also counts, for the owner who set it up, five steps: the page opened, a field touched, a video or photo added, the testimonial sent, and one of the review sites the business offers after sending opened. Each is a number that goes up by one. Nothing about you is attached to it, nothing you were typing, and never which review site. Since 12 October 2026 it also counts, on the same terms, which of the form's questions a visit reached — by the question's place on the form, the first time its field was touched — and the recorder and the permission box, once each per visit, sent together when you leave the page or send the form; and when you send, which of those your visit had reached. Each is a number that goes up by one, per form and month, kept for about thirteen months: never what you typed, which answer you chose, or who you are. Those review-site links are the business's own addresses, opened directly with nothing added to them and no referring address sent; what you post there is between you and that site.

A business's testimonials, shown on its own website or on a wall we host for it, count for that business how often they were shown, how often a video was played and how often a reader followed a link to where a testimonial was first written. Each of those counts is kept under two labels as well: the name of the site your browser says you were on before — its name only, such as news.ycombinator.com, never the page, and “direct” when your browser names no other site — and the utm_source and utm_campaign tags on the address of the page you are reading, when it has them. A label is shared by everybody who came the same way; nothing that identifies you is part of it, and nothing is stored in your browser for it. (If the business is running a lift test, nothing of it is stored in your browser, read from it or sent to us, and you are not counted in it, until the business's own site tells the widget you agreed — through its consent banner, or Google Consent Mode — or states that its visitors' law asks no consent for it; that statement is the business's, and we do not check it. If you refuse or withdraw through that banner, the entry is removed. Once you have agreed, the widget keeps one entry in your browser, saying which of the test's two groups it was drawn into, with a random number your browser draws for that one test. The number is sent to us with your browser's count in the test and with a purchase, and we keep it with the test's figures, only so that a purchase is counted for a browser the test really counted, and only once; it is not linked to your name, your address, your device or any other site, and it is deleted with the test's figures, when the business starts a new test or deletes the project, and at the latest about thirteen months after the test began.) That entry also keeps two labels from the visit that put your browser in the test: the name of the site you came from, or “direct”, and the path of the page you were on, without anything after a “?” or “#” and with anything that looks like a long number, an id or an email address replaced. Both stay on your own device, and are sent to us only with the test's count of you as a reader and of your purchase, so the business can see how the test came out by where readers came from and by page. A purchase may also carry the business's own name for what was bought, such as “annual”, and, when the business's page names it, the id its payment provider gave the order: that id is kept beside the browser's random number, with the test's figures and deleted with them, only so that the same order reported again by the business's server or store is counted once.) When a company's AI crawler that names itself — GPTBot or ClaudeBot, for example — reads a wall we host, one is added to a count for that crawler's name, and nothing else about the request is kept.

A business's widget also sends us the name of the site it is on — the page's host, such as acme.com, never the page or anything after it — with each request for the testimonials and each press of a video, so that a business that lists its own sites is not shown on, or counted from, pages it did not choose. When the widget cannot draw on a page — nowhere to draw, drawn at no size, a layout that does not exist, an error while drawing — it sends us that page's host, its path without the part after a “?” or “#” and with anything that looks like a long number, an id or an email address replaced, and which of the four it was. Nothing about you is part of it: no identifier, no referring site, nothing you typed. So that a page reports each thing once a day rather than on every visit, the widget keeps one entry in your browser, in that business's own site's storage, listing what it already reported that day; it is replaced the next day and is never sent to us. The widget keeps that entry, and sends such a report at all, only once that business's site says you agreed (or that the law where it operates asks no consent for it), the same answer the lift test waits for; if you refuse, the entry is removed. Adding ?hazelsong=debug to a page's address makes the widget explain itself in your browser's console, and sends nothing.

On a wall we host, a business may add a button of its own — its words, its link. When you press it, one is added to a count for that wall, under the same two labels as a showing, and you go to the business's address exactly as it gave it: we add nothing to that address and send you through nothing of ours.

A business can also choose to have its widget, or the window that opens its collection form, tell the analytics its own website already runs — Google Analytics, Google Tag Manager, Plausible, Fathom or Umami — when its testimonials are shown, a video is played, a link to where one was first written is followed, the form is opened, or a testimonial is sent. It is off unless the business turns it on, and it is the business's own tool and the business's own choice: those events go to that business's analytics under its own privacy terms, not to us. What goes with them is the layout the testimonials were drawn in and the published testimonial's public id — never your name, anything you wrote, your address, or which group of a lift test your browser was placed in. The widget loads no analytics script for this; it only calls one the page had already loaded, and it sends nothing from an automated browser or from the business's own marked one.

A business can also open its collection form in a window on its own website or app. When it does, the script keeps one entry in your browser, in that business's own site's storage — not ours: the time the window was last shown or closed, and whether you sent a testimonial through it. It holds no identifier and is never sent to us; its only use is to keep the window from asking you again within the time the business chose, and not at all once you have written. The script keeps it only once that business's site says you agreed (or that the law where it operates asks no consent for it), the same answer the lift test waits for; until then the business's own code cannot open the window by itself, nothing is stored, and the window still opens when you press the business's own button to write. If you refuse, the entry is removed. If the business passes your name and email address to fill in the form, they travel in the part of the form's address after the “#”, which your browser does not send to us, and the form removes them from its address as soon as it has read them; they are kept only if you send the testimonial, like anything else you type into it.

If a business asks you for a testimonial through us and you choose "Not now", we keep a fingerprint of your address — a one-way code made from it, not the address itself — on that business's list, so that nothing it sends through us asks you again. Only you can take it back, by writing to them anyway; it is removed when the business deletes its project.

A request, and its one reminder, may carry a link to a page that plays a short video the business recorded for everybody it asks. The page shows the business's name and the recording and nothing about you: it reads nothing from your device, keeps nothing about you, and asks for the recording only when you press play. The link carries the business's key to the recording and the id of your request, which the page uses only to hand you your own link to the form. We do not learn whether you opened it: the page counts nothing about you, and the play is counted only against the business's own allowance.

When we send a message to you for a business — a request, its one reminder, a thank-you or a request to share what you wrote — our mail provider tells us whether it could be delivered. We read two of its reports and nothing else: that your mail server refused the message for good (the address does not exist, for example), and that you marked it as spam. Either one puts the same kind of fingerprint of your address on that business's list, with which of the two it was and when, and nothing more is sent to you through us for that business. The request is shown to the business as “Undelivered” or “Marked as spam”. To match a report to the business, each message carries a code made from the business's project — never your address — and we keep, for 120 days after the last message, which project that code belongs to. We never learn whether you opened a message or followed a link in it: there is no tracking pixel and no tracking link. A business can take an undeliverable address off its list once it has been fixed; nobody can take off a complaint of spam. All of it is removed when the business deletes its project.

To compare addresses on these lists, a Gmail address is read without the dots in its name and without anything from a “+” to the “@”, and googlemail.com as gmail.com, because Gmail delivers all of those to one inbox; addresses at other providers are compared as typed, apart from capital letters. This is only for comparing: messages always go to the address exactly as it was given.

Each time a business asks somebody for a testimonial through us, by any route, we keep a fingerprint of the address and when it was asked, so that the same person is not asked again sooner than the business chose (every 90 days unless it chose otherwise). It is removed when the business deletes its project.

A business can also send us an order so that its buyer is asked once, later. We then keep the buyer's name and address on that business's list of requests, exactly as if the owner had typed them in; and the order's id, so the same order is never asked about twice. The amount is used to apply the business's own rule about which orders to ask about, and is not kept with the request.

A business may instead connect its store — Stripe, Shopify, WooCommerce or Lemon Squeezy — so that the store itself sends us each paid order and each refund. The store sends the whole order as it describes it; we read the buyer's email address, name, the amount, the order's id and the business's lift test reference out of it, and the order's currency, which is only compared with the currency of the lift test's figures and not kept; we check that it came from the store, and do not keep the rest of the message. When the order begins a subscription, we also read the subscription's id, and when the store reports a renewal of it, the renewal's amount and id: the subscription's id is kept with the lift test's count of that order, only so its renewals are added to the same group, and goes when the test does. For each connection we keep the store's signing secret, which the business pastes in so we can check that each order really came from its store, and when the last delivery arrived and what came of it. We never hold the store's API key and never call the store. The connection and its secret are deleted when the business disconnects the store or deletes its project.

What happens to a testimonial, and where it goes

We don't sell personal data, we don't train anything on testimonial content, and we don't use it to market Hazelsong. It is not, however, only stored and displayed: it is sent to the services below to be read, transcribed or translated, and that is set out here rather than left to be discovered.

Testimonials — whether they arrive through a form or are imported — are sent to Anthropic and read for risk before the owner decides what to do with them: a promised result, a named third party, a regulated claim, a private detail. Two cases are not sent at all, and are named here rather than left to be assumed: a testimonial that arrives after the day's allowance of readings for that project is used up, and one that arrives while no reading service is configured. Those are stored unread and the dashboard says so; nothing about them goes to Anthropic. A reading that is attempted and then fails is not one of those two cases: the text had already been sent. Where the owner has switched on automatic moderation, a testimonial written through their collection form that passes its checks is sent to Anthropic once more — its words, the name, role and company it was written under, and its rating, never the writer's address — to decide whether it may be published as written. What it decided and why is kept with the testimonial, seen by the owner's team and in the owner's export, and goes when the testimonial goes; it is never shown to readers. While a testimonial waits for that check, a record of the task is kept with the project: its attempts (times, the kind of failure, the provider's request number and the tokens it reported, never the provider's message) and, between the answer and the decision, a copy of the fields that were read. The copy is removed once it is decided; the record of attempts is kept for 30 days, or 90 when the check could not run, and goes with the testimonial or the project. When the reading for risk on arrival does not come back because the service was busy or slow, the testimonial is marked as waiting for it and the same record of attempts is kept while it is tried again; its words are sent again only on those attempts. When the owner has webhook endpoints, an approval or a writer's withdrawal waiting to be sent again is kept in a webhook outbox for at most three hours: the endpoint, the event, the signed message (for an approval, the testimonial as the API shows it; for a withdrawal, only its id and when) and how many tries it has had. It is removed once it is delivered or given up, before a later try if the testimonial is no longer approved, and with the project. A withdrawal is sent to the owner's endpoint even when their month of API calls is used up, once per testimonial; to keep it once, the project holds the testimonial's id beside the endpoint's, and nothing else, until the project is removed. The same service is used, at the owner's request, to propose which span to remove, to draft a short pull quote, to write the reports and case studies drawn from testimonials already collected, and to translate a testimonial while keeping the original. Three more uses happen only when the owner presses their button: to suggest labels for a testimonial, Anthropic is sent the published version of that testimonial and the project's own list of labels; to answer a question the owner asks about their testimonials, it is sent the question and the published words of up to the 200 most recent testimonials approved for the owner's website (the first 600 characters of each, with no names or addresses); and to draft questions for a form, it is sent the one sentence the owner wrote about their business. To draft a reply when the owner or a teammate presses “Draft one for me”, it is sent the business's name, the writer's first name, their rating, their words and the note typed beside the button, never the writer's address; the draft is shown in the reply box and not stored unless it is sent as a reply. The help assistant in the dashboard sends what is described under “The help assistant in the dashboard” above. None of what comes back is stored as anybody's words. Audio and video sent for transcription go to whichever speech service is configured — Deepgram, OpenAI's Whisper, or Google — and the name of the one that produced a transcript is stored with it. Deepgram and OpenAI are sent a recording only once their data processing addendum is signed and recorded in our configuration; until then they are sent nothing. Each of these is sent only what the task needs, and only to perform it for you.

The companies that hold or process this data for us:

  • Vercel — hosting, the storage that holds videos and photographs, and, when a project is started or a login link asked for, a check that a person's browser sent the request rather than a program, made by reading the browser's answer to a small challenge.
  • Upstash — the database everything else is written to.
  • Anthropic — reading for risk, proposing a removal, drafting pull quotes, writing reports and case studies, translating testimonials, suggesting labels, answering the owner's questions about their testimonials, drafting questions for a form, and answering questions to the help assistant in the dashboard.
  • Deepgram, OpenAI and Google — transcription of audio and video, whichever of them is configured; Deepgram and OpenAI only once their data processing addendum is signed and recorded. Every request to Deepgram carries its opt-out from using what it is sent to train its models.
  • Resend — sending the product's email, and reporting whether a message to a business's customer could be delivered or was marked as spam.
  • Paddle — taking payment, as merchant of record, the billing page where you change your card or cancel, and, under Paddle Retain, the messages and the window that recover a payment that did not go through.

What each of them receives, what its own terms say and the transfer mechanism it names are listed in our Data Processing Addendum, which also lists a new one at least 30 days before it receives anything.

Data location and retention

Text, ratings, permissions, transcripts and translations are stored in a managed Redis database; videos and photographs are stored as files in Vercel Blob. Both are retained for as long as the project exists. When a paid plan ends and no plan is started again, the projects it paid for are deleted 30 days after it ended, after three emails to the account's address (when it ends, 14 and 7 days before that day), never sooner than 7 days after the last of them, and only once the payment provider confirms the subscription has ended (Terms of Service, "After a paid plan ends"). A record of which notices were sent and when is kept until then, under a one-way code made from the account's address. The projects' owners can download everything until that day. Deleting a testimonial from the dashboard removes it from the database and deletes its files from storage, immediately and permanently; if storage refuses at that moment the record still goes, and a daily sweep deletes any file no testimonial points at anymore. Deleting the project does the same for everything it holds: the project is closed to new testimonials first, and if the deletion stops part-way, the rest is deleted automatically within a day.

Business email sender details

The project owner may save a business name and mailing address for customer emails. We store these separately from public testimonial data and bind the confirmation to the current owner email. They are included in outgoing customer email, are not placed on hosted testimonial pages, and are removed when the project is deleted. Only enter an address you intend to disclose to recipients. Saving these details does not establish permission to contact a person.

Records of permission for email requests

The business owner can record a contact basis, evidence reference, dates and selected email purposes for each recipient. These are owner statements, not independently verified consent. We store the latest record under a fingerprint of the exact email address, separately from public testimonial data. The records are bound to the current owner email and removed with the project. Earlier evidence must be retained by the business; replacing a record does not create a complete historical audit trail. Publication choices do not supply permission for contact, and do-not-ask preferences remain effective.

New email requests include a separate link to stop further requests from that project. It remains usable after answering a testimonial or changing the dashboard access key, while the project exists. A private signing key is stored for the project and removed with it. The link carries signed fingerprints instead of your email address; its secret stays in the URL fragment until your browser reads and removes it. Opening the page does not opt you out: pressing the button records your refusal. The refusal cannot be undone by the business owner or by adding a contact-permission record. Service receipts and private replies remain separate. Previously sent messages cannot be recalled.

Affiliates and referrals

Following a referral link sets no cookie. The page it opens carries a random id for that click in its address and asks whether you allow one cookie, hz_via, holding that id and nothing else, for up to 60 days, so that whoever shared the link is credited if you sign up or subscribe later. Only “Allow the cookie” sets it. Without it nothing is stored in your browser, and the id reaches us only if you sign up or open the payment page from the page the link opened, carried in the form or the address. We keep that id with the link it came from for 60 days, and count clicks and sign-ups per link per day. We do not keep the visitor's IP address, browser or any other detail of the click. If the visitor signs up or subscribes, we record that their account came through that link, under a hash of their email address rather than the address, and, for each plan payment, the plan, the date, the amount the link earned and the payment provider's customer id, so a refund can cancel it and credit can be applied. The person who shared the link sees counts and amounts only, never who the business is.

An affiliate gives us their name, email address, PayPal address, where they will recommend us and how, and the date they accepted the terms; we use these to run their account and send payouts, and ask for a tax form before the first one. When an affiliate leaves, we delete their account, link and counts, and keep the record of payouts already made for as long as tax law requires. A customer's referral link is kept with their email address so that their credit can be applied to their bill.

Your rights

Wherever you are, you may ask us for a copy of the personal data we hold about you, and to correct it, delete it, restrict what we do with it, or receive it in a common machine-readable format; and you may object to what we do on the basis of our legitimate interests. Where something rests on your consent, you may withdraw it at any time, as easily as you gave it, without affecting what was done before. Write to support@hazelsong.com. We may ask you to confirm the request from the address it concerns, and we answer within 30 days of receiving it, or sooner where the law that protects you sets a shorter time. A project's owner can also download everything in it at any time with the CSV export, and delete it from the dashboard.

If you wrote a testimonial, the business you gave it to decides about it: ask the business, or ask us and we will pass your request to it the same way, without deciding it ourselves. A writer who used a collection form also has a private link to withdraw it.

Where the EU or UK GDPR applies, each use of personal data needs a legal basis. For what we decide about ourselves, ours are:

  • Your account and the service: creating and running your projects, login links, the dashboard, connected assistants, handing a project over, and the emails about your projects — to perform our contract with you.
  • Billing: your plan, the payment provider's ids, packs, refunds and chargebacks — to perform our contract with you; and the accounting and tax records the law requires us to keep — a legal obligation.
  • Security: the one-hour fingerprints of network addresses, the limits on sign-ups and login links, the browser check and the handling of abuse — our legitimate interest in keeping the service and the people in it safe from automated abuse.
  • Content notices and removal requests: our legitimate interest in answering them, and a legal obligation where a law requires us to act on a notice.
  • Support email and the help assistant: to perform our contract with you, or, for somebody who is not a customer, our legitimate interest in answering them.
  • The affiliate program: an affiliate's account and payouts — our contract with them, and a legal obligation for the tax forms and payout records; which link a business came through — our legitimate interest in crediting the right person. What is stored on a visitor's device for it, and when, is under “Affiliates and referrals”.
  • The home page's question: our legitimate interest in counting which tools visitors use, without telling one visitor from another.
  • Requests a person refused, and addresses that bounced or complained of spam: our legitimate interest in never asking them again through us, which is the only way to honor their refusal.

For everything a business collects through Hazelsong — its testimonials and their writers' names, addresses, photographs and recordings, the permission records, the risk reading, moderation, transcription and translation done for it, the requests it sends, its store's orders, its lift test and its walls' and widgets' counts — the business is the controller and chooses its own legal basis; we process it only on its instructions, under the Data Processing Addendum, and the companies we use for it are listed there. A writer's permission to publish their testimonial is a permission to publish it where they chose. It is not, by itself, the legal basis for processing their data, and it is not consent to anything being stored on a visitor's device or to a visitor being followed.

Transfers to other countries

Most of the companies listed above are based in the United States, and Paddle in the United Kingdom, so personal data is processed there and wherever their own terms say; we may also open it from elsewhere, only for the reasons under “When we look at your account”. The regions in which our database and file storage hold data are not yet stated here. For the data a business collects through Hazelsong, the EU standard contractual clauses and the UK Addendum are part of the Data Processing Addendum; for our own transfers to those companies we rely on the mechanism each one's own terms name, which the addendum lists beside each.

How long your account's records are kept

What a project holds is kept while it exists and deleted as under “Data location and retention”. Your account's own record — your email address, your plan, the payment provider's customer and subscription ids, and your summary settings — stays after your last project is deleted, so that a subscription still running can be matched to you, until you ask us to delete it. Invoices and receipts are kept by Paddle or Stripe under their own terms. Support email and content notices are kept in our mailbox until we delete them; there is not yet an automatic schedule for them.

Complaints

Tell us first at support@hazelsong.com: we acknowledge a complaint about how we handle personal data within 30 days and tell you what we did about it. You may also complain to a supervisory authority at any time: in the EU or the EEA, the data protection authority of the country where you live or work, or where you believe the problem happened — the European Data Protection Board lists them at edpb.europa.eu; in the United Kingdom, the Information Commissioner's Office, at ico.org.uk; in Canada, the Office of the Privacy Commissioner of Canada, at priv.gc.ca; in Brazil, the Agência Nacional de Proteção de Dados, at gov.br/anpd. Some of those authorities ask that you raise it with us first.

If you live in the United States

Several US states give their residents rights over their personal data, and each decides by its own thresholds which businesses its law covers. Whether or not one of those laws covers us, we answer anyone in the United States the same way as under “Your rights”: you may ask to know what personal data we hold about you and receive a copy of it, to correct it, and to delete it. We do not sell personal data, we do not share it for advertising aimed at you on other companies' sites and apps, and we do not use it for targeted advertising or to build a profile of you. Using any of these rights changes nothing about the price or the service you get. Someone you authorize may ask on your behalf; we may ask you to confirm the request from the address it concerns. If we decline a request, you may appeal by replying to our answer with the word “Appeal”, and we tell you in writing what we decided and why within 60 days. For a testimonial and the rest of what a business collects through Hazelsong, the business decides, as above.

The person in charge of personal information

The person in charge of the protection of personal information at Hazelsong, whose title and contact information Quebec's Act respecting the protection of personal information in the private sector asks every enterprise to publish, is its operator, named at the top of this policy. Title: operator. Contact: support@hazelsong.com. A request to see or correct personal information we hold is answered in writing within 30 days of receiving it.

Our record of security incidents

We keep a record of every security incident that involves personal data we hold or process, whether or not the law required anyone to be told about it: when it happened and when we learned of it, what kind of data it concerned and how much, how we judged the risk of harm, whom we told and when, and what we did about it. Each entry is kept for at least 24 months after we determine that the incident happened. Where an incident affects data a business collects through Hazelsong, we tell that business within 48 hours of learning of it, as the Data Processing Addendum says, so that it can decide what it owes its own customers.