Roster. Home Terms

Last updated 1 November 2026

Privacy Policy

Roster is a reporting tool for advertising agencies. It reads Google Ads and Meta ads data on your behalf, and never writes to your advertising accounts. This policy explains what it stores, why, and how to get rid of it.

1. Who we are

Roster is operated by Roster Pvt Ltd, at H.No 1905, Sector 4, Rewari, Haryana, India (“we”, “us”). We are the data controller for the account information described below. For the Google Ads and Meta performance data you bring into Roster, you are the controller and we act as a processor on your instructions.

Questions, requests and complaints go to gauravkr.contact@gmail.com.

2. What we collect

Account details
Your email address and a password. Passwords are never stored in readable form — we keep only a salted scrypt hash, and cannot recover your password.
Session cookies
One cookie that identifies your signed-in session, and a short-lived cookie used while you connect Google or Meta, to prevent request forgery. Both are httpOnly, so page scripts cannot read them. Neither is used for measurement. See section 8.
Analytics cookies
Google Analytics sets a cookie that gives your browser a random identifier, so that the pages you open in one visit are recognisable as one visit rather than as several unrelated strangers. It holds a random number and nothing else — not your name, not your email, and nothing typed into Roster. Section 7 says what it is for, and how to refuse it.
Workspace details
The client names you create, and which Google Ads accounts and Meta ad accounts you attach to each. These are typed or chosen by you and may identify your clients.
Branding
If you set them: your agency’s name, logo, browser-tab icon, accent colour, website and contact line, and for each client a display name, a logo and a colour. Logos are stored in our database. All of it appears on the share links you send, so treat it as public once a link is out.
Google Ads data
Account names and IDs, campaign names and IDs, and performance figures such as spend, impressions, clicks and conversions. Rendered reports are stored as dated snapshots so a report keeps its history and a client link does not go blank mid-refresh.
Google account identity
The email address of the Google account used to connect, shown so you can tell which login a workspace is using.
Meta ads data
The ad accounts the connecting login can reach — their names and IDs, currency, time zone and the business portfolio that holds them — so you can choose which belong to each client. For the accounts you choose: campaign names and IDs, and performance figures such as spend, impressions, reach, clicks, video views, engagement and the one conversion action you pick for a report, with breakdowns by age, gender, country, region, platform, placement, device and hour of day. These are totals Meta reports for an ad account; none of them identifies a person who saw an ad. Reports keep them as dated snapshots, as they do Google Ads figures.
Meta account identity
The name and Meta user ID of the Facebook account used to connect, shown so you can tell which login a client is using.

We do not collect payment card details, and we do not ask for or store credentials for any service other than the Google and Meta authorisations described below.

3. Google user data

When you connect a workspace, Google asks you to authorise Roster and then issues us a refresh token. We store that token encrypted at rest using AES-256-GCM and use it for one purpose: reading the Google Ads data needed to render your reports.

Roster requests the https://www.googleapis.com/auth/adwords scope, which Google classes as sensitive, plus your Google account email address. The adwords scope permits writes; Roster performs read operations only and never creates, edits, pauses or deletes anything in your advertising accounts.

Roster's use of information received from Google APIs adheres to the Google API Services User Data Policy, including its Limited Use requirements. Specifically, we do not use Google user data for advertising, we do not sell it, we do not transfer it except as described in section 6, and we do not allow humans to read it except where you have asked us to for support, where it is necessary for security or to comply with law, or where the data is aggregated and de-identified.

You can revoke Roster's access at any time from your Google account permissions page, or by disconnecting the workspace inside Roster. Disconnecting deletes the stored token and the list of accounts attached to that workspace.

4. Meta user data

When you connect Meta for a client, you sign in with Facebook Login for Business and Meta issues Roster a user access token that lasts 60 days. We store that token encrypted at rest using AES-256-GCM and use it for one purpose: reading the Meta ads data needed to render your reports. When it expires, Roster asks you to connect again.

Roster requests two permissions: ads_read, to read the performance of the ad accounts you choose, and business_management, to find the ad accounts held in your business portfolios so that you can choose among them. business_management permits changes to a portfolio; Roster only reads it. Roster never requests ads_management, and never creates, edits, pauses or deletes anything in your ad accounts or your business portfolios.

Roster's use of data received from Meta complies with the Meta Platform Terms. We use it only to produce your reports. We do not sell or license it, use it for advertising, use it to build profiles of people, or transfer it except as described in section 6, and we do not allow humans to read it except where you have asked us to for support, where it is necessary for security or to comply with law, or where the data is aggregated and de-identified.

You can remove Roster's access at any time by disconnecting Meta in the client's settings inside Roster. Disconnecting deletes the stored token, the ad accounts you chose for that client and the list of accounts the login could reach, and withdraws Roster's permissions at Meta, so Roster also disappears from your Facebook settings. You can also remove Roster from Meta's side, under Business integrations in your Facebook settings; Roster can then read nothing more, and the token it holds is useless until you disconnect it in Roster or ask us to delete it (section 12).

5. Why we process it

We do not use your data to train machine learning models, and we do not sell it.

6. Who we share it with

We use a small number of processors, each only for the function named:

Google (Google Ads API, Google OAuth)
The source of the advertising data, and the identity provider for connecting it.
Meta (Marketing API, Facebook Login for Business)
The source of the Meta advertising data, and the login used to connect it.
Google Cloud (Cloud Run)
Hosts the application. Region: asia-southeast1 (Singapore).
Neon
Hosts the Postgres database holding everything in section 2.
Google Analytics
Usage measurement — which screens are opened, which features are used, and what fails. Sent under an internal account identifier that means nothing outside our database. See section 8.
Anthropic
Only if you choose to design reports using Claude. In that case the report definition and the account structure it is based on are processed by Anthropic under its own terms. No Google or Meta token is ever sent to Anthropic.

We may also disclose information if compelled by law, or as part of a merger or acquisition, in which case we will tell you before your data becomes subject to a different policy.

A report's own page, /r/<report-id>, needs you to be signed in. What you send a client is a share link, /s/<token>: viewable without signing in, read-only, and pinned to the figures as they were when you made it. The token is long and random, and we do not list or index these pages — but anyone who has the link can see that report. Treat a share link as you would treat the report itself, and revoke it from the report page if it should stop working.

Share links carry your branding, not ours. They are measured like every other Roster page: when someone opens one, we record that it was opened, which of the report’s pages they moved to, and how long it was read, under the rules in section 8, and the same banner offers them the same choice about the analytics cookie.

8. Analytics and cookies

We measure how Roster is used, on this site and inside the product, with Google Analytics. We are telling you plainly what changed here: this used to run in a cookieless configuration, and it no longer does.

The old setup set no cookie and kept no identifier at all. It was also close to useless. With nothing linking one page to the next, every page you opened looked like a different person arriving, so we could count that reports get shared and count that people sign up, and never learn whether anyone who signed up ever got as far as sharing one. The questions that decide what we build next — where setup goes wrong, which step people give up on, what fails and how often — all need one visit to be recognisable as one visit.

So Google Analytics now sets a cookie holding a random identifier. What that buys is continuity: your page views in one visit join up, and if you sign in they join up with your next visit too. Alongside it we send an internal account identifier — an opaque string from our database, never your email or your agency's name — so that we can tell that the same account used the dashboard and the Claude connector, rather than counting you twice.

What we do not do

Your choice

If you are in the EEA, the UK or Switzerland, analytics storage starts switched off and stays off unless you choose “Allow” on the banner. Nothing is stored on your device for measurement before you answer. Everywhere else it starts on, and the same banner turns it off — choose “No thanks” and no analytics cookie is kept. Your answer is remembered in your browser’s local storage, so we only ask once. Clearing your browser data asks again.

Google also publishes a browser add-on that opts you out of Google Analytics on every site, ours included.

What is recorded

What is never sent

The cookies Roster sets itself are the two described in section 2 — your sign-in session and the short-lived one used while connecting Google or Meta. Both are strictly necessary to log in at all, and neither is used for measurement.

Activity inside Roster

Separately from what your browser sends, Roster's servers record what is done inside the product:

We use these records to keep Roster working — to see what fails and why, and to fix it — and to decide what to build next. Neither sets anything on your device, so neither depends on the banner above: they are part of running the service you signed up for. The connector record is visible only to us and deleted after 90 days (section 9).

9. How long we keep it

Deleting a workspace deletes its Google and Meta connections, its attached accounts, its branding and logo, its reports and their snapshots.

10. Security

No system is perfectly secure. If you believe you have found a vulnerability, please write to gauravkr.contact@gmail.com before disclosing it publicly.

11. Your rights

Depending on where you live, you may have the right to access, correct, export, restrict or delete your personal data, to object to processing, and to complain to a supervisory authority. To exercise any of these, email gauravkr.contact@gmail.com. We will respond within 29 days.

One practical note: a single Roster login may be shared by several people at your agency, so we cannot always tell which individual performed an action. If you need per-person accountability, ask us and we will tell you what is and is not attributable.

12. Deleting your data

You can delete most of what Roster holds yourself, without asking us:

To delete your whole account, or anything Roster holds about you or a Facebook or Google login you used with it, email gauravkr.contact@gmail.com from the address you sign in with, or tell us the Facebook or Google account concerned. We will delete it within 30 days and write back to confirm, keeping only what the law requires us to keep. Analytics records are deleted as described in section 9.

13. Children

Roster is a business tool and is not directed at anyone under 16. We do not knowingly collect data from children.

14. Changes

If we change this policy in a way that materially affects how we handle your data, we will email account holders and update the date at the top. Continued use after that date means you accept the revised policy.

15. Contact

Roster Pvt Ltd
H.No 1905, Sector 4, Rewari, Haryana, India
gauravkr.contact@gmail.com