Privacy notice

Last updated 1 September 2026.

This is the privacy policy for Effective Advocacy Project — the application you sign in to at app.effectiveadvocacyproject.org, the API behind it, and the research they draw on. It does not cover the public website at effectiveadvocacyproject.org.

Effective Advocacy Project studies how public policy is argued and writes briefings for non-profit advocacy organisations. It holds personal data about two different groups, and this policy covers both: the people who sign in and use the application, in sections 1 to 3; and the people the research is about, in section 4, most of whom never signed up for anything.

Who we are

  • Controller: Lucence Limited, 9 Queen’s Road Central, Central, Hong Kong. Effective Advocacy Project is a service operated by Lucence Limited.
  • Contact, including for objections and erasure: info@lucenceltd.com.
  • EU representative (GDPR Art. 27): being appointed. Until then, write to the address above.

We decide what is collected, why, and what is done with it — research included — so Lucence Limited is the controller, not a processor acting on another organisation’s instructions. Partners receive finished briefings; they do not direct what we collect.

1. Information the application collects about you

Access to the application is by invitation only. There is no public sign-up: an administrator creates an account against your email address before you can sign in at all. What we collect from you is what running that account requires.

  • Account information. Your email address, your name, the organisation you belong to, and which projects you have been granted access to.
  • Sign-in records. The one-time sign-in links we email you and whether they have been used, and your session. If you sign in with Google, the link to your Google account — see section 3.
  • API tokens. If you use the API, a hashed copy of your token and a monthly count of the requests made with it, which is what enforces the token’s quota.
  • What you write in the application. Feedback you leave on a briefing — the thumbs and the comment box — which is attributable to you by name, and questions you type into Ask. Questions are sent to a language-model provider in order to answer them.
  • Usage records. Which parts of the application you open and when — signing in, the pages you visit, and the briefings you open. We keep this ourselves, in our own database; it is not shared with anyone and no third-party analytics service is involved. We use it to tell whether what we produce is being read.
  • Cookies. Two, both strictly functional: one keeps you signed in, the other remembers the last project you were reading. There are no advertising or analytics cookies, and the application loads no third-party tracking scripts.
  • Technical logs. Ordinary server logs — IP address, time, the URL requested, and the browser used.

We do not ask for and have no use for payment details, location data, your contacts, or any special category of personal data about you.

2. How we use that information, and our legal basis

  • To sign you in, and to keep you signed in.
  • To show you the briefings and analysis your organisation has been granted, and to keep everything else out of reach.
  • To answer the questions you ask in Ask.
  • To keep the service working and secure: enforcing token quotas, spotting abuse, and investigating faults.
  • To improve what we produce — feedback on a briefing is how we learn what to cover next.
  • To contact you about the service, including telling you when this policy changes in a way that matters.

Our legal bases are the contract with your organisation, and our legitimate interest in keeping the service secure and improving it.

We do not sell your personal information or pass it to data brokers, do not use it for advertising, and do not use it to train AI or machine-learning models.

3. Google user data — what the application accesses, uses, stores and shares

Google sign-in is optional — the application works just as well with an emailed link — and it does exactly one job: proving you control an address an administrator has already granted access to. It never creates an account. If your address is not already on the list, signing in fails. This section sets out how the Effective Advocacy Project application accesses, uses, stores and shares Google user data.

  • What we access. The standard sign-in scopes only: openid, email and profile. That gives us your Google account identifier, your email address and whether Google has verified it, and your name. We request no access to Gmail, Drive, Calendar, Contacts or any other Google service, and we never use the resulting token to call one.
  • What we use it for. Signing you in, and nothing else. We use Google user data only to provide and improve user-facing features of the application, and for no other purpose. It plays no part in the research and is not used to decide what appears in a briefing.
  • What we do on your behalf. Nothing. The application takes no action in your Google Account or in any other Google service, and creates, changes and deletes nothing there.
  • What we store. Your email address, a display name, and the identifier of the Google account linked to it, together with the sign-in tokens Google issues. We do not store your Google profile picture.
  • Who we share it with. No one. Google user data is not passed to our service providers and is never sent to a language-model provider — what goes to those is the public material described in section 4, never your account details.
  • How we protect it. It is held in the same EU-hosted database as the rest of the application, reachable only over an authenticated connection, and only by the people who operate the service. See section 6.
  • How long we keep it, and how to remove it. 90 days after your access ends, as in section 7. You can disconnect the application from your Google Account at any time and carry on with the emailed link, and if you ask us we will delete it sooner.
  • What we never do with it. We do not use Google user data for advertising of any kind, including targeted, personalised, retargeted and interest-based advertising; do not sell it or transfer it to data brokers or information resellers; do not use it to train generalised or non-personalised AI or machine-learning models; do not use it to determine credit-worthiness or for lending; and do not use, transfer or disclose it for any purpose other than providing and improving user-facing features of the application.

Effective Advocacy Project’s use and transfer of information received from Google APIs to any other app adheres to the Google API Services User Data Policy, including the Limited Use requirements.

4. Information we hold about people the research is about

This is much the larger group, and its members are not users of the application. If you take part in policy debate in public — as an elected representative, official, registered lobbyist, journalist, campaigner, or named consultation respondent — we may hold your name, role and affiliation, links to your public profiles, what you said or published and where, its attribution to you, and analysis derived from it, including whether a passage of yours supports or opposes a policy position.

Where it comes from. All of it comes from publicly available and official sources; we do not collect private accounts, direct messages, or anything behind a login. We did not get it from you, and we cannot write to everyone individually — so this notice is how we tell you, which is what GDPR Art. 14 asks of us.

Our lawful basis is legitimate interests (GDPR Art. 6(1)(f)): understanding how public policy is argued, for non-profits working on those policies. It cannot be done without names, and it concerns what people said acting in a public capacity. We do not sell the data. Where a recorded position amounts to a political opinion, we rely on Art. 9(2)(e): it was made public by the person concerned.

Language models summarise and score; people decide what to do with the result. Nothing here makes an automated decision with a legal or similarly significant effect.

5. How we share information

We do not sell personal data, and we do not share it for advertising. We share it in three circumstances only.

  • Service providers. We use providers for hosting, email delivery, language-model processing, and media monitoring and search. They act on our instructions; a current list is available on request. Document text — the public material in section 4, other people’s words and names — goes to language-model providers. Your account details do not.
  • Your own organisation. An administrator at the organisation that granted your access can see that you have an account and which projects it reaches.
  • Where the law requires it. If we are legally obliged to disclose something, or need to in order to establish or defend a legal claim.

6. Data security

The application and its database are hosted in the European Union. Traffic is served over HTTPS; API tokens are stored hashed, never in the clear; access to the database is authenticated and limited to the people who operate the service; and application secrets are held in a managed secret store. Access to a project is checked both in the application and again in the API behind it, so a partner cannot reach a project they have not been granted. No system is perfectly secure, and we do not claim otherwise — if something goes wrong we will tell affected people and the relevant authority as the law requires.

7. How long we keep information

Criteria rather than promises.

  • Portal accounts: 90 days after access ends.
  • Sessions and sign-in links: by expiry.
  • Server logs: 90 days. Monthly API usage counters, which enforce a token’s quota: 12 months.
  • Feedback: as long as the briefing it comments on.
  • Briefings: the partner relationship, plus two years.
  • The research corpus: material about people acting in a public capacity for as long as the research needs it — the value is watching a debate move over years. Material about private individuals is not held on that basis; we take it out when we find it, and whenever anyone asks.

8. Your rights and choices

Whether you use the application or appear in the research, you can ask what we hold about you, receive a copy of it, correct it, restrict it, object to it, or have it erased. Write to info@lucenceltd.com and say who you are.

If you are in the research corpus

If you object to being in the corpus we will take you out of it, and we will not ask you to justify the request. Requests are handled by hand — there is no self-service delete — and we aim to reply within 30 days. If we take you out we keep a minimal note of the request, so that our collection does not pick you up again; that note is all an objection leaves behind.

If you use the application

You can ask an administrator to change or remove your access at any time, and you can disconnect Google sign-in from your Google Account while continuing to sign in by email. You can also complain to a data protection supervisory authority.

9. International transfers

The application and database are hosted in the EU. We run the project from Hong Kong, which has no EU adequacy decision — that is us reaching our own data rather than handing it to anyone else, but it does mean the information is worked on outside the EU, and some of our providers are outside it too. We are putting the European Commission’s standard contractual clauses in place where they are needed; this page will name them once they are signed, not before.

10. Children

The application is for staff of partner organisations. It is not intended for children, we do not knowingly collect personal data from anyone under 16, and there is no way to obtain an account without an administrator creating one.

11. Changes to this policy

If this changes we will update the policy, move the date at the top, and email people with accounts if the change matters.

12. How to contact us

Write to info@lucenceltd.com, or to Lucence Limited, 9 Queen’s Road Central, Central, Hong Kong. See also the terms of use.