Cookie Policy

This page explains what we store in your browser to run Podify and, with your consent, to understand how it is used — and how to change that choice at any time. Our Privacy Policy covers what we collect about your account; this page is only about cookies and the equivalent browser storage.

Two categories, one choice

A banner appears the first time you visit and asks you to accept, reject, or customize. It offers two switches — Analytics and Marketing — on top of what is strictly necessary and always on. Behind those switches are the seven signals Google Consent Mode v2 defines. Here is exactly how your choice maps onto them:

Rejecting, or simply closing the banner without choosing, leaves every signal in the two switchable rows at its denied default. The strictly-necessary row is not part of that choice — it is granted either way, which is what makes it strictly necessary. Nothing we set for analytics or marketing is stored until you say so. The choice itself is kept in this browser's local storage, under podify.consent, until you change it or clear this site's data.

One thing is not covered by that choice, so we name it here rather than let you discover it: episode and topic pages, a search result once you press play on it, and a creator's widget once you open a video in it, embed the YouTube player. We load the player in YouTube's privacy-enhanced mode, from youtube-nocookie.com, where YouTube sets no cookies when the player loads. Two things still reach YouTube's own storage. First, episode and topic pages also load YouTube's player script from youtube.com as soon as they open, and youtube.com can set its own cookies then. Second, once you press play, YouTube may keep data of its own in your browser's local storage. Both happen whatever you answered above. That data belongs to Google, not to us — we can neither read it nor switch it off, and it is governed by Google's own privacy policy. The only way to avoid it is on your side: block third-party cookies and storage in your browser.

One more thing is stored without asking, and this one is ours: a small marker that keeps a creator's own visits out of their hub's visit counts. It is saved when a creator opens their hub from their dashboard, or when anyone opens a hub link that carries our preview parameter — then only until the browser tab is closed — and the hub pages that count visits check whether it is there. The copy saved from the dashboard holds the date it expires: 30 days after the creator last opened their hub from the dashboard, or sooner if you clear this site's data. The tab copy holds the value "1". Each is saved under the name of the hub it applies to: no identifier, nothing about who you are, and nothing that is sent to us. Our Privacy Policy describes it under "Counting visits to your hub".

What loads, and when

We use Google Tag Manager to run Google Analytics. The container does not load at all — no request to Google's servers — unless you accept at least one of Analytics or Marketing. Accepting only Marketing loads it too, with the Analytics signal still denied: Google's analytics tags in it then send Google cookieless pings — the page you are on and the events it records, without setting or reading any Analytics cookie. There is no fallback that loads it for visitors without JavaScript, so if your browser cannot run our consent script, you are simply not tracked.

Revoking your consent takes effect immediately for Google's own tags, which read the updated signals. What it cannot do is unload a container that already started running in this tab — once it has loaded, it stays loaded until you reload the page or close the tab, and following a link to another page of this site does not unload it. Until then its tags keep sending Google cookieless pings for the pages you open and the events you trigger in this tab, with the signals denied. After that reload, with both Analytics and Marketing off, the container is simply absent.

On some hubs, a separate measurement script runs: the creator's own Google Analytics property, not ours. They connect it themselves, from their own settings; what it collects goes to their property, and we never read it. It answers the Analytics switch on the same banner above — nothing extra to accept, and nothing else turns it on: accept Marketing while leaving Analytics off and it never loads at all. One banner, one decision on this page, not two. Revoking updates its signals immediately; what it cannot do is unload a copy already running in this tab — that stays until you reload the page or close the tab, and following a link to another page of the hub keeps it sending a pageview for each page, with the Analytics signal denied. What our code asks it to send is a pageview each time you open a page on this hub — no search text, no email address, nothing from your Podify account. Google's script can record more on its own, though: the creator's property settings decide whether it also measures things like scrolling and clicks on links that leave the site (Google calls this enhanced measurement and switches it on by default), and those settings are the creator's, not ours. Like any Google Analytics property, it uses Google Analytics cookies in your browser: _ga, a random per-browser number that lets repeat visits count as one visitor instead of several, and _ga_ followed by the property's id, which keeps track of your visit on that property. Both are set only after you accept Analytics. Neither is your name, and the creator's property only ever receives what happens on their hub — but they are identifiers, so we would rather name them than let you find them in your cookie list. The cookies belong to the website you are on: on a creator's own domain our own container runs too, so there the creator's property shares _ga with ours, and ours adds its own _ga_ cookie, and on podifyapp.co the _ga cookie is the same one our own analytics uses. Reject Analytics, or never answer, and they are never set at all. Switching it off after you had accepted is different, and we would rather be exact: nothing new is written from then on, but the cookies already in your browser stay there until they expire or you clear them yourself. We do not delete them for you; your browser's settings do, for this site and any other.

The identifier behind Analytics

The events that carry an internal account identifier all come from our billing system: a completed subscription payment, a plan change, and a cancellation. Our server sends each one to Google Analytics directly. The identifier is an internal reference — not your email address, your name, or your hub's public address — and it is what lets a purchase be matched to the visit that led to it. The events your browser sends do not carry it. Because these events do not come from your browser, they use the browser identifier recorded at your latest checkout, which records one only if you had accepted Analytics there, and they are not sent without it. Refusing Analytics at a later checkout stops them; switching Analytics off in the banner stops what your browser sends, and it does not stop these. Deleting your account sends Google a deletion request for that identifier and the Analytics data tied to it. Google confirms that it accepted the request, not that the data is gone — the erasure happens on their side, on their schedule, and it is the only answer their API gives us. What we hold ourselves goes with the account, except the records our Privacy Policy lists as kept after deletion, each with the reason, and our server logs, which that policy says we keep while they are operationally useful.

How long the analytics data is kept

Our own Google Analytics property keeps the event data for 14 months, then deletes it automatically. Aggregate reports — visit counts and the like, with nothing tied back to an individual — outlive that window. If you delete your account before then, the deletion request described above asks Google to erase the events tied to your account identifier without waiting for the 14 months to run out. A creator's own property keeps what it receives for as long as that creator has set it to — Google's default is 2 months — and we can neither see nor change that setting.

If you reach us through a creator's own domain

Some hubs are published on a custom domain instead of podifyapp.co. Browsers keep cookie and storage choices separate per website, and a custom domain is a different website from ours — even though it shows you the exact same banner. So if you visit a hub on podifyapp.co and then the same hub on its own custom domain, you will be asked to choose again. There is no way around this without a third-party consent service shared across every domain, which we do not run. Our own container runs there too, under that domain's banner choice, and sends what it measures to our property.

Changing your choice

You can reopen the banner at any time, with your current choice preselected, and save a different one.

The sign-in cookies

Separately from all of the above, we set the cookies sign-in needs: one that keeps you signed in for 30 days, plus a few our authentication library uses to protect the sign-in form and to complete the Google round-trip — those end with your browser session, or within 15 minutes for the Google round-trip. They are strictly necessary to use an account at all, so they are not part of the choice this page describes, and our Privacy Policy covers them.

Changes to this policy

If we materially change what we store or why, we'll update the date at the top of this page.

Contact

Podify is operated by Cristian Filimon, trading as Amaze Labs (NZBN 9429053396341), New Zealand. Questions about this policy go to [email protected]. See also our Privacy Policy.