Privacy Policy

Your account

Signing in with Google gives AdServeKit your email address, display name and profile picture, plus the stable account identifier Google uses to recognise you on the next visit. When you authenticate using Google, AdServeKit requests basic identity scopes (openid, https://www.googleapis.com/auth/userinfo.email, and https://www.googleapis.com/auth/userinfo.profile) solely to authenticate your identity, create or link your user account, and display your name and profile picture in workspace settings. AdServeKit never receives your Google password and cannot act on your Google account.

If you register with an email address instead, AdServeKit stores that address, the display name you choose, and your password as an Argon2id hash — a one-way transformation that cannot be reversed to recover the password. Confirming your address, and any later password reset, uses a single-use link whose token is itself stored only as a hash and expires. Nothing here is shared with Google.

Sessions record the browser’s user agent and a keyed hash of the source address — the address itself is never stored, and the hash cannot be reversed to recover it. You can see and revoke every active session from your account page.

Google data, and why we ask for it

The marketplace only works if the figures next to a listing can be trusted. A seller typing their own traffic numbers into a form proves nothing, so AdServeKit asks the platform itself instead. Connecting a Google service is how a publisher turns “take my word for it” into evidence an advertiser can rely on — it is the source of truth behind every verified figure on a marketplace listing.

Both connections are optional, approved by you explicitly, and read-only. AdServeKit cannot change anything in your Google account, post anything, or see anything the scopes below do not cover.

One detail worth being exact about: when Search Console is enabled on this deployment, the Google sign-in screen offers its read-only permission alongside sign-in rather than asking separately. Google shows it as a tick box you can clear, and clearing it costs you Search Console reports and nothing else — sign-in works either way. We read what was actually granted, so declining is a real choice rather than a formality.

AdServeKit’s use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. Google data is never sold, never used for advertising targeting, and never transferred to anyone except as needed to provide the features described above.

Refresh tokens are encrypted with AES-256-GCM before they are stored, under a versioned key, and each ciphertext is bound to the row it belongs to. Data already imported into your reports stays until you delete it — losing access does not erase your history.

Search Console and YouTube share a single Google permission, because Google adds the second to the first rather than issuing a separate one, and Google can only withdraw that permission as a whole. So disconnecting one of them stops AdServeKit using it straight away, but the permission and its stored credential are kept while the other is still connected. Disconnecting the last one revokes the permission at Google and deletes the stored credential. You can also remove AdServeKit’s access yourself at any time from your Google Account permissions, which ends both connections at once.

Data Security and Protection

AdServeKit takes reasonable technical and organizational measures to protect personal information and Google user data against unauthorized access, disclosure, alteration, loss, or destruction.

We use the following safeguards:

• Encryption in transit: Data transmitted between users, AdServeKit, and Google services is protected using HTTPS/TLS encryption.
• Protection of authentication credentials: Google OAuth access tokens, refresh tokens, API credentials, and other sensitive authentication information are protected against unauthorized access and are accessible only to systems and personnel that require them to provide the requested services.
• Encryption at rest: Sensitive Google user data and authentication tokens stored by AdServeKit are encrypted at rest where applicable (using AES-256-GCM encryption with versioned keys bound to specific database records).
• Access controls: Access to production systems and sensitive user information is restricted using authentication, authorization, and least-privilege access controls.
• Secure credential handling: Passwords and authentication credentials are not stored in plain text. Passwords are saved only as Argon2id hashes, and secrets and API credentials are kept separate from publicly accessible application code.
• Data minimization: AdServeKit only requests and processes Google user data necessary to provide features explicitly requested or enabled by the user.
• Monitoring and maintenance: We maintain security controls and regularly update our systems and dependencies to reduce the risk of unauthorized access or exploitation.
• Data retention and deletion: Google user data is retained only for as long as necessary to provide the applicable service, satisfy legitimate operational requirements, or comply with legal obligations. Users may disconnect their Google account and request deletion of associated data at any time.
• No sale or advertising use: Google user data is not sold, transferred to data brokers, or used for personalized advertising, retargeting, or determining creditworthiness.
• AI and machine-learning restrictions: Google user data obtained through Google APIs is not used to develop, improve, or train generalized or non-personalized artificial intelligence or machine-learning models.
• Human access restrictions: Under Google Limited Use requirements, human personnel are strictly prohibited from accessing or reading Google user data, unless: (1) we have obtained the user’s affirmative agreement for specific messages or technical support inquiries; (2) it is necessary for security purposes (such as investigating abuse or a security incident); (3) it is required to comply with applicable law or valid legal processes; or (4) the data is aggregated and anonymized for internal operational needs.

AdServeKit’s use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

If we become aware of a security incident involving personal or Google user data, we will investigate the incident, take appropriate remediation measures, and provide any notifications required by applicable law or Google policies.

Other platforms you can connect

Where a deployment enables them, Facebook Pages, Instagram professional accounts and TikTok accounts can be connected on the same basis and for the same reason: to prove control of a profile you want to list, and to display the public follower and content totals the platform itself publishes. The permissions requested are the minimum each platform offers for that purpose, statistics permissions are optional, and you never need a developer account or an API key of your own. Disconnecting one of these revokes its access where the platform offers a way to, and deletes the stored credentials either way.

Analytics we collect from your websites

When you install the AdServeKit tag, it records what happened on the page: page views, session starts, engagement (time on page and scroll depth), and any conversion events you choose to send. Each event carries the page URL, the referring URL, the device type, the browser and operating system family, and a country derived from the source address.

To tell a returning visitor from a new one, the tag stores a random identifier in the browser’s local storage, and a separate one for the current session. They are created by the browser, contain nothing about the person, and stay until the visitor clears their site data. No cookie is set for this.

That identifier is not what we keep. It is sent with the event and immediately replaced with a keyed hash, mixed with a secret held only by this deployment and with the identity of the website it came from; only the hash is written to our analytics tables. Because the key is secret the hash cannot be reversed, and because the website is mixed into it, the same visitor produces a different hash on every publisher’s site — so there is no cross-site identifier, and a visitor cannot be followed from one publisher’s site to another’s. Raw IP addresses are treated the same way: used to derive a country and a keyed hash, then discarded.

A visitor whose browser sends a Global Privacy Control or Do Not Track signal is exempted from all of this: no identifier is created, nothing is stored on their device to recognise them, and the visit is counted without one. The signal is honoured by the tag on the page and again by the server that receives the event, so it holds even if the page is stale or the script is tampered with. Every key the tag can store, and its lifetime, is listed in the cookie and browser storage policy.

Event data is retained for a period this deployment’s administrator configures, then removed by a scheduled sweep. Aggregated daily figures are kept longer than the individual events they were built from, because a report should not disappear when its raw rows age out.

You are the controller of the data collected from your own websites, and responsible for whatever notice or consent your visitors are owed where you operate. The terms on which we process it for you are in the Data Processing Addendum.

How ad delivery works

When a page with an ad slot loads, the tag asks this deployment for an advertisement, sending the slot size, the page URL and the referring URL. The server chooses from campaigns that are live, in schedule, within budget and matching the targeting — country, device and time of day — and returns one, or returns an honest “nothing to serve” with a reason.

Advertisements render inside a sandboxed frame with an opaque origin and no network access, so an advertisement cannot read the page it appears on, cannot set cookies on the publisher’s domain, and cannot call out to anywhere. Clicks are counted by this deployment and forwarded to the destination.

There is no auction, no bid request, and no third party in the request path. Nothing about a visitor is sent to any external advertising or data company, because there is none — the only server involved is this one.

Reporting an advertisement

The badge on every advertisement lets a reader report it. A report keeps the reason chosen, anything the reader typed, which advertisement it was and where it ran, a coarse country and device class, and a copy of the advertisement as it was at that moment, so that it can still be reviewed if the advertiser later changes it.

So that one person reporting the same advertisement many times counts once, the report also keeps a keyed hash derived from the reader’s network address and browser, the advertisement and the date. The address itself is not stored. Because the advertisement and the day are mixed into the hash, it is different for every advertisement and every day, and cannot be used to recognise a reader elsewhere or to link their reports together.

Reports are read by this deployment’s moderation staff. The advertiser is told that their advertisement was reported and in which category, but never who reported it or what they wrote. When a moderator decides something, the advertiser sees the decision and any explanation written for them; moderators’ internal notes are never shown to advertisers. Moderation decisions and their history are kept for as long as the advertisement’s record is, so that decisions can be reviewed and appealed.

The marketplace

Publishing a marketplace profile makes it public: the property name, its address, what you wrote about it, and the verified figures for it. That is the point of listing, and it is entirely opt-in — a property you import stays private until you publish it.

Your account’s sign-in address is never published. Contact details on a listing are only the ones you type there on purpose. Messages between an advertiser and a publisher are visible to both sides and to this deployment’s administrators.

Operational logs

Separately from the analytics above, the servers keep ordinary operational logs: the time of each request, the path, the method, the status code, the browser’s user agent, and the source address it arrived from. These exist to keep the service working and to investigate abuse and outages — they are what makes an error you report findable. They are not analytics, are never joined to the measurement tables, and are not used to build a profile of anyone.

This is the one place a raw source address is written down. Where this policy says an address is not stored, that is about the analytics tables, where it genuinely never appears: it is turned into a country and a keyed hash on arrival and the address itself is dropped. The operational logs are the exception, they are held on the server rather than in the product, and they are kept for a short period and then rotated away.

Billing and invoicing

If you use AdServeKit to invoice your own customers, it stores what an invoice legally has to carry. For you as the supplier: your trading name and address, your tax and VAT registration numbers, and the bank details you want printed on the document, including IBAN and SWIFT/BIC. These are business identifiers that appear on the invoice itself — they are stored so the document can be produced, and are never used to take a payment. AdServeKit does not process card payments and holds no card numbers.

For the people you invoice: the name, billing address, email address and tax or VAT number you enter for each customer, the invoices and credit notes issued to them, and whether and when each was marked paid. Those are your customers, not ours. You decide what to record about them, and AdServeKit holds it on your behalf — you are the controller of that data and we process it only to produce and deliver the documents you ask for.

An invoice you send carries a link with a token in it, so the recipient can read and download their bill without an account here. Anyone holding that link can open that one document, which is why the page is never cached by a shared proxy, sends no referrer, and should be treated as confidential.

Billing records belong to the workspace rather than to you personally, so deleting your own account does not delete them: invoices, credit notes and their payment records remain with the workspace, which is also what lets an issuer meet the retention periods tax law imposes on them. Removing them is a separate request — ask us and we will act on it, subject to any retention the law requires of the issuer.

Deletion and retention

Deleting your account removes your websites, campaigns, creatives, placements, analytics configuration, Search Console and social connections, SEO audits, marketplace properties and listings, and your visible activity history — and replaces the identifying fields on your account record with a non-identifying placeholder. Files you uploaded are removed from storage along with the records that named them, not just the records.

Google user data retention and deletion: Google OAuth tokens are retained only for the duration of an active connection. You can disconnect your Google account at any time via your account settings or integrations page, or revoke permissions directly in your Google Account permissions. Upon disconnecting, stored tokens are revoked and purged. Deleting your account permanently deletes all stored Google credentials, cached Search Console statistics, and linked YouTube channel records. You can also request the immediate deletion of your Google user data at any time by contacting support@adservekit.com.

Deletion is scheduled rather than immediate, so there is a window in which you can change your mind. A few things can hold it up, and the account page says so at the point of asking rather than failing later: a workspace with other members or pending invitations, campaign history shared with another workspace, and marketplace conversations — because the other side of a conversation has its own record of it, which is not yours to erase. Resolve or transfer those and the deletion proceeds.

Security records are retained: authentication events, administrative actions and the append-only security audit log. They exist so that a compromise can be investigated after the fact, which is only possible if they cannot be removed on request. They carry account identifiers and timestamps, never session cookies, OAuth tokens or request contents.

Third parties

The application itself is self-hosted, and there are no analytics, advertising or tracking services embedded in this dashboard — the fonts it uses are served from this deployment rather than fetched from a font provider. Three kinds of third party are nonetheless involved in running it, and naming them is more useful than claiming there are none.

The identity providers you choose. Google for sign-in and, if you connect them, Search Console and YouTube; Facebook, Instagram or TikTok if you connect those and this deployment enables them. Each is described above.

A network provider in front of this service. This deployment is reached through Cloudflare, which terminates the connection and passes it on. Like any such provider it necessarily sees the addresses and requests passing through it, under its own terms rather than this policy. It is infrastructure, not a recipient of your data: nothing is shared with it for its own use.

An email provider. Verification links, password resets, invitations, notifications and the invoices you send are delivered through a transactional email service, which necessarily handles the recipient’s address and the message itself in order to deliver it. Mail is sent because you or your workflow asked for it, never for marketing.

Contact and privacy inquiries

For any questions about this Privacy Policy, your personal information, or Google user data, or to submit a data deletion, access, or export request, please write to support@adservekit.com or visit our support page.

The guides explain what each connection does and how to manage or disconnect your integrations at any time.