Privacy policy

Our customers are the businesses who sign up and use the dashboard. Their users are the people using our customers’ apps and websites, whose activity our customers send us through our SDKs. For their users’ data, our customer decides what is collected and why; we process it on their behalf and on their instructions.

From our customers: your name and email address when you sign in, the projects you create and the people you invite, and settings you choose. We do not use passwords — you sign in with a one-time code or with Google or GitHub.

From their users, through our SDKs: the events an app chooses to send (for example, “opened the app” or “made a purchase”), device details such as model, operating system and app version, the description of itself that a browser or app sends with every request (its “user agent”), and two things worked out from the network connection: an approximate location — country, region and city — and the name of the network the connection is on, such as an internet provider or a mobile carrier. The IP address is used to work those out and is not stored, with the one exception described next.

We use the same details to recognise visits to a website that are made by automated programs rather than people — search engines’ crawlers and the like — or that probably are. Unless the website’s owner has chosen to keep them, those visits are discarded as they arrive and nothing about them is stored.

For measuring advertising: when an app has turned it on, which ad or link led to an install, taken from the app store’s own referrer (including the campaign details Meta places there, which we decrypt with a key the app’s owner gives us), from Apple’s attribution services, or from a code the link passes to the app. When a website using our SDK is visited from an ad, we record which ad sent the visit — the ad network’s own click identifier from the page’s address — so an install that follows can be credited to it.

On landing pages we serve for an app or a business: we record that the page was seen, which of its buttons were pressed, how far it was read and that a form was sent, with the campaign tags in the page’s address, the name of the site that sent the visit (never the address of the page on it), and a cookie holding a random value on the page’s own address for a year, so that one browser’s visits are understood as one visitor. Each visit is given a code that the page’s buttons carry to the app’s store page, into the app, and to the business’s own websites — and to no other site. If that code comes back from the app after it is installed or opened, or from the business’s own website when it is visited, we treat the page’s visitor and that person as the same person, because the code proves it. We do not do this on a guess, unless the app has turned on matching by network and device (below) and also chosen to join people on such a match. The visitor’s page visits then form part of that person’s history, including which landing page they saw first and last, and are erased with it.

If an app has also turned on matching by network and device for iPhone, then when somebody taps one of its links, or arrives on its website from an ad, we keep a scrambled (hashed) form of the IP address — for a newer (IPv6) address, of its network part — for six hours, with the browser’s language and whether the device is a phone or a tablet. On the app’s own website we also keep the device’s time zone and screen size. We set a cookie holding a random value, for six hours, on the link’s address and on the website’s own domain, so that taps and visits from the same browser are understood as one person rather than several. If the app is first opened from the same network in that time, on a device that matches what we kept, we treat the most recent tap as probably having led to the install, and label it as probable wherever it is shown. What we kept is deleted when it is matched or when the six hours end, whichever comes first, and the address itself is never stored.

While Treebars is in private beta, you can join a waitlist on this site. We keep the email address you give us and whatever else you choose to tell us — your name, company, role and website, the platforms you build on, roughly how many people use your product, and what you would use Treebars for. We also keep where you came from (the campaign tags in the link you followed, the site that sent you, and the first page you opened here) and the country your connection is in. We do not keep your IP address.

We use this to confirm your address, to show you your place in line, to decide whom to let in and when, to tell you when you’re in, and — unless you turn it off — to send you occasional news about Treebars and the beta. It is stored where the rest of our data is and the emails are sent through Cloudflare; we share it with nobody else.

We ask you to confirm your address first. If you never do, we delete what you gave us after seven days. Every email we send about the waitlist has a link to your place in line, where you can stop the updates or leave the list — leaving deletes your entry straight away. You can also write to privacy@treebars.com and we will delete it for you. If you are let in and create an account, your entry is linked to it, and deleting your account deletes the entry too.

When you report something on our abuse page, we keep the address you report, what you say is wrong with it, the details you write, and your email address if you choose to give one. We do not keep your IP address. The report is mailed to our abuse team and listed for them in our console; we use your address only to tell you what we did. We keep a report for as long as we need to show what was done about it, and we share it with nobody except where the law requires — a report of child abuse material is passed to the authorities.

We use Treebars itself to understand how this website and the Treebars dashboard are used, the way a customer uses it for their own product.

On this website we record the pages you open, the buttons and links you press, and that a form was sent — not what you typed into it. With that we keep what your browser tells any site: its type and language, the description of itself it sends with every request, your time zone, the size of your screen, the page that sent you here and the campaign tags in the link you followed. We work out the country, region and city your connection is in and the name of the network it is on, and do not keep your IP address. To understand several visits as one browser, a random identifier is kept in your browser: in its local storage, and in one first-party cookie, so that this website and the dashboard recognise the same browser. The cookie is ours alone, is never used for advertising and is read by nobody else. If your browser sends Global Privacy Control or Do Not Track, none of this happens: nothing is recorded and nothing is stored.

In the dashboard, where you are signed in, we record the screens you open and the actions you take — that a campaign was published, for example, never what it says — together with your account’s id, email address and name, the project you were working in and your role in it. We do not record the contents of your project: not your users, your events, your messages or your keys. If you visit this website while signed in, your visits here are joined to the same account. While a Treebars employee has your account open to help you, which the dashboard tells you, nothing they do is recorded as you.

Paying for a project is the one place where we record amounts. When you look at plans, choose one, pay for it, change or cancel it, or top up a balance, we record each step and its figures: which plan and whether it is billed monthly or yearly, its price, the amount of a top-up with its tax and total, what you set a spend cap or an automatic top-up to, and Paddle’s ids for that checkout and payment. We record what Paddle tells us happened afterwards in the same way, under the account that pays for the project: each payment and renewal, a payment that was refused and Paddle’s one-word reason, a cancellation, a refund. These are sums paid to us, and we use them to understand our own sales. We never record your card — not its brand, not its number — only whether a card or PayPal paid.

If somebody shares a board with you and you open it on Treebars’ own boards address, we record that the board was opened and which of its pages you looked at, in the same way and without your name. We do not do this where a board is shown on a company’s own domain or inside another product.

We may show you a message on this website or in the dashboard — about a new feature, for example — and when we do we record that it was shown and whether you pressed or closed it.

We use this to see what is used, what is confusing and what fails, and to decide what to build. It is kept with the rest of our data, handled by the same processors, shared with nobody else, and never used for advertising. To have what we hold about your use deleted, write to privacy@treebars.com.

Paddle (Paddle.com) is our merchant of record: it sells Treebars on our behalf, takes the payment, charges the tax and issues the receipt. You give your card details to Paddle, on its own checkout, and we never see them. Paddle’s own privacy notice covers what it collects there.

What Paddle tells us: its own ids for you as a customer, for each subscription and for each payment; which plan and price a subscription is for, its status and the period it has paid for; and the amounts of payments, refunds and chargebacks. We keep each of its notifications as the record of what happened, and remove the card’s details and the billing address from it as it arrives.

What we tell Paddle: the price a checkout or a top-up is for, our own ids for the project and for that checkout or top-up, so its notifications can be matched back, and the email address of the account that is paying, so its form does not ask you for it again. Nothing else you have typed into Treebars, and nothing about your project’s users.

Before a top-up is charged, the dashboard shows which card it will use: the brand and the last four digits of the card your plan was last paid with. We read those from Paddle at that moment, to show them to you, and do not store them. The list of a project’s invoices on its Plan & usage page is read from Paddle the same way, each time the page is opened, and the invoices themselves are Paddle’s files.

Paddle’s script runs in two places and nowhere else: on the dashboard’s Plan & usage page, from the moment you start a checkout there, and on this website’s checkout page, where the links Paddle emails you open. The dashboard opens Paddle’s customer portal, where you change your card and download invoices, in a separate tab.

On Cloudflare’s network and in databases run by Neon (PostgreSQL) and Tinybird. Account credentials you connect to us — for example an advertising account — are encrypted before they are stored and are never shown back, not even to you.

We do not sell personal data and we do not use it to advertise to anybody.

Data leaves only where a customer has told it to: messages they send through email, SMS, push or other channels they connect; files delivered to storage they own; and results sent back to an advertising network they have connected (described below). Our processors — the hosting and database providers named above, and the providers that deliver messages — handle it only to provide the service. Paying for Treebars goes through Paddle, as described above, and nothing about a project’s users goes with it.

A customer can connect their own Google Ads, Meta or TikTok account so that, when somebody who arrived from one of their ads does something the customer cares about, we can tell that advertising network. This is what lets the network learn which ads work.

What we send is the network’s own click identifier, the name of the event, when it happened, and its value — nothing else, unless the customer separately turns on matching by a scrambled (hashed) email address. We also read the account’s campaign names and its daily ad spend, so the customer can see what their ads cost next to what they earned.

We use that access for exactly those purposes and nothing else. We do not use it to show ads, we do not sell or share it, and no person at Treebars reads it except to fix a problem the customer has asked us to fix, for security, or where the law requires it.

Treebars’s use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

In particular, data we receive from Google is used only to provide the features a customer has asked for — sending their conversions to their own Google Ads account, and reading their campaign names and ad spend — and is not used for serving advertisements, not sold, and not transferred to anybody except as needed to provide those features, for security, or to comply with the law.

Event data is kept for as long as the customer’s plan says, and then deleted or moved to an archive the customer controls. Account data is kept while the account is open. A customer can disconnect an advertising account at any time, which deletes the stored connection immediately.

When a batch of events cannot be processed, we keep it whole for up to 30 days so it can be tried again, and then delete it. That holds after a request to delete someone’s data too: the copy waits out its 30 days, and if it is tried again, nothing in it about that person is kept.

If you use an app that uses Treebars, the app’s maker is the right first contact — they decide what is collected, and they can ask us to delete everything about you, which we do. If you are a Treebars customer, you can see, export or delete your data, or close your account, by writing to us.

privacy@treebars.com