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
- 2. What we collect
- 3. Google user data
- 4. Meta user data
- 5. Why we process it
- 6. Who we share it with
- 7. Shared report links
- 8. Analytics and cookies
- 9. How long we keep it
- 10. Security
- 11. Your rights
- 12. Deleting your data
- 13. Children
- 14. Changes
- 15. Contact
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
scrypthash, 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
- To provide the service — signing you in, fetching your Google Ads and Meta figures and rendering reports. This is necessary to perform our contract with you.
- To keep the service secure — session handling, abuse prevention and audit. This is our legitimate interest.
- To run and improve the product — a record, made by our own servers, of what is done inside Roster: the actions taken in the signed-in dashboard and every request Claude makes through the Roster connector, as described in section 8. This is necessary to provide the service and is our legitimate interest; it does not depend on consent.
- To understand how the product is used — usage analytics with Google Analytics, as described in section 8. Where the law requires consent for the analytics cookie, that is our basis for it, and you can withdraw it at any time.
- To meet legal obligations — where we are required to retain or disclose information.
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.
7. Shared report links
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
- No advertising cookies, ever. Advertising storage, advertising user data and ad personalisation are switched off permanently in our configuration, and nothing on the consent banner can turn them on. Roster does not advertise and builds no audiences.
- No cross-site tracking, and no sharing of anything with data brokers.
- We do not sell anything to anyone.
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
- which page or screen was opened, and in what order;
- approximately how many seconds a page, or a section of a page, was visible and in front of you;
- product events — a workspace created, a Google Ads or Meta account connected, branding saved, a report shared, a report link opened by a client and which of its pages were opened, a request to Claude succeeding or failing — with a count or a short label (such as “demographics” for a page) where one is meaningful;
- a random identifier for your browser, and our internal account identifier if you are signed in;
- rough shape-of-account facts in bands rather than exact figures: whether you have connected Google Ads at all, and whether you have one client or several;
- coarse technical context supplied by any browser request — device type, browser, language, and an approximate location derived from the IP address, which Google discards rather than storing.
What is never sent
- your name or email address;
- your clients’ names, or any workspace, report or task name you have typed;
- Google Ads or Meta account IDs, campaign names, or any advertising figure;
- error messages. When something fails we send a category — “permission”, “quota”, “not found” — and never the message itself, because those messages quote what was being asked for. The full text stays in our own database.
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:
- Actions in the signed-in dashboard — creating a workspace, connecting Google Ads or Meta, saving, arranging or sharing a report, a share link being opened — are sent from our servers to Google Analytics under our internal account identifier, with the same exclusions as the list above: no names, no emails, no figures.
- Every request Claude makes through the Roster connector is recorded in our own database: which tool was called, what it was asked (its arguments, which can include the workspace, campaign or report it was about, and the report design itself), how long it took, whether it succeeded, the error if it failed, and a short summary of the result — counts, and the IDs and names of anything it created. It never includes the figures a request returned. Google Analytics receives only the tool’s name, whether it succeeded, roughly how long it took, and on failure a category such as “quota”.
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
- Account and workspace records — until you ask us to delete them.
- Google refresh tokens — until you disconnect the workspace or revoke access at Google, whichever comes first.
- Meta access tokens — until you disconnect Meta or delete the client. Meta stops accepting a token after 60 days, or as soon as you remove Roster at Meta; connecting again replaces it.
- Meta ad account lists — the accounts you chose and the list the login could reach, until you change them, disconnect Meta or delete the client.
- Report snapshots — retained as history so past reports remain viewable. Deleted with the report or the workspace.
- Sessions — expire automatically, and are destroyed when you sign out.
- Connector requests (the record of Claude’s requests in section 8) — 90 days, after which each record is deleted automatically.
- Branding — until you change or remove it. A logo you replace or remove is deleted when you save; a client’s logo is deleted with that client’s workspace.
- Analytics — 14 months, the retention period configured in Google Analytics, after which the event-level records are deleted and only aggregate totals remain. Analytics records carry a random browser identifier and, when you are signed in, our internal account identifier; ask us and we will delete yours.
Deleting a workspace deletes its Google and Meta connections, its attached accounts, its branding and logo, its reports and their snapshots.
10. Security
- Google refresh tokens and Meta access tokens are encrypted at rest with AES-256-GCM.
- Passwords are stored as salted
scrypthashes and are not recoverable. - Traffic is served over HTTPS.
- Session cookies are
httpOnlyandsameSite, and sessions are revoked server-side on sign-out rather than left to expire. - Each workspace's data is scoped to its owning account in the database query itself, so a mistaken identifier returns nothing rather than another agency's records.
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:
- Meta — disconnect Meta in a client’s settings. This deletes the token and the ad account lists, and withdraws Roster’s permissions at Meta (section 4).
- Google Ads — disconnect the workspace, or revoke Roster at Google (section 3).
- A report — delete it, and its snapshots go with it, Google Ads and Meta figures alike. Disconnecting alone leaves reports you have already made, and their figures, in place.
- A client — delete the workspace, and everything listed at the end of section 9 goes with it.
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