Your data security is our top priority. Learn about the measures we take to protect your information and maintain compliance with global standards.
We do not currently claim a completed SOC 2 Type II examination. Contact our security team to discuss the documentation available for your review.
Our privacy policy and data processing agreement describe how personal data is handled and how to submit a data rights request.
Our privacy policy explains applicable consumer rights and the contact route for questions about access, deletion and data use.
We do not currently claim ISO 27001 certification. If certification is a purchasing requirement, raise it with our security team before subscribing.
| Standard | Status | What to check |
|---|---|---|
| GDPR | Privacy information | See the privacy policy and data processing agreement |
| CCPA | Privacy information | See the privacy policy and data processing agreement |
| SOC 2 Type II | Not claimed | No completed SOC 2 Type II examination claimed |
| ISO 27001 | Not claimed | No ISO 27001 certification claimed |
| HIPAA | Not applicable | We do not process PHI by design |
| PCI-DSS | Not applicable | Card data handled exclusively by Stripe (PCI Level 1) |
For procurement questions, send the controls and documents your organization requires to [email protected].
Ask about testing scope, hosting, data access and the requirements that matter to your organization.
If you require independent testing documentation, ask which systems were tested, when the work took place and which findings are covered by the available evidence.
A website summary is not a penetration test report. Confirm the scope and date before relying on any testing document in a procurement decision.
The authoritative, current sub-processor list (Hetzner/AWS, Stripe, Postmark, Sentry, Cloudflare) — with purpose, data accessed, and region for each — is maintained in one place to prevent drift.
View sub-processor list →Security researchers are welcome. We commit to acknowledging reports within 48 hours, no legal action for good-faith research within scope, and recognition in our hall of fame.
We implement multiple layers of security to ensure your data is protected at every level.
MyClickShield integrates with the Google, Meta and Microsoft advertising APIs solely to provide click fraud protection to the authenticated advertiser. We never sell or share API data with third parties.
OAuth scope: https://www.googleapis.com/auth/adwords
Purpose: Detect invalid clicks and help advertisers reduce wasted ad spend.
Services called:
CustomerService.listAccessibleCustomers — list authorized Google Ads accounts during OAuth setup.GoogleAdsService.searchStream — read ENABLED campaigns so we know where to apply IP exclusions.CampaignCriterionService.mutate — add / remove negative IP_BLOCK criteria on campaigns. Every mutation is reversible from the dashboard.ConversionAdjustmentUploadService.uploadConversionAdjustments — upload RETRACTION adjustments for flagged clicks (opt-in).User control: Every automated action is configurable, reversible, and auditable from the MyClickShield dashboard. The user may revoke OAuth consent at any time. We do not read or modify ad content, budgets, billing, targeting, or keywords.
Permissions: ads_management, ads_read, business_management
Purpose: Filter invalid traffic from Facebook and Instagram advertising campaigns.
Services used:
User control: The user can review every exclusion and disable automated actions at any time from the MyClickShield dashboard.
OAuth scope: https://ads.microsoft.com/msads.manage
Purpose: Protect Microsoft Ads campaigns from invalid traffic.
Services used:
User control: All changes are logged, reversible, and disabled by default until the user explicitly opts in.
All data is encrypted in transit (TLS 1.3) and at rest (AES-256). OAuth refresh tokens and API credentials are stored in an encrypted secrets store and never exposed in logs or error messages.
Customer data is stored in isolated database tables with strict row-level access controls. Production databases are backed up daily and backups are encrypted with separate keys.
Click-level data is retained for the duration of the subscription plus a grace period of 30 days. Aggregated, non-identifiable statistics may be retained for longer for product analytics.
Account deletion requests are processed within 30 days. Upon deletion, OAuth tokens are revoked, personal data is removed, and API connections to advertising platforms are terminated.
Multi-cloud infrastructure with automatic failover and geographic redundancy across US and EU regions.
300+ edge locations via Cloudflare for low-latency fraud detection worldwide.
Choose where your data is stored. EU-only processing available for European customers.
Our security team is available to answer your questions and provide additional documentation for your compliance requirements.
Review the service documents alongside your website's consent settings and access arrangements. Identify what information is involved, who can see it and what happens when you stop using the service.
Involve the person responsible for privacy or security in your organization if they need to approve the installation. Ask about any requirement the documents do not answer, and keep the relevant terms with the date you reviewed them.
Read the provider's privacy information, service terms and data-processing documents before installing a tracker. Identify the information the service uses and who in your business will access it. If someone else manages privacy or website consent for your organization, involve them early so the installation fits the way your site is set up.
Ask specific questions where the documents do not answer your needs: how long records are kept, how access is managed, what you can export and what happens when you stop using the service. Check the tracker with your existing consent configuration and other website tools. Keep visitor records and account credentials out of public contact forms; agree an appropriate support route if an investigation needs sensitive information. Save the relevant documents and the date you reviewed them. Revisit the setup when you change the website, advertising accounts or the people who can access the reports.
Use an account owner or someone with the appropriate access to connect your advertising account. Before authorizing the connection, check the business name and account ID, especially if you manage several clients. Review the permissions shown in the connection process and confirm which campaigns you intend to protect. Keep account passwords and private credentials out of shared spreadsheets and support messages.
Decide who will check the connection if access expires or a member of staff leaves. A disconnected account can still require attention even when the website tracker is collecting visits. If actions are no longer being applied, inspect the connection status before assuming traffic has become clean. When taking over an account from another agency, ask which integrations and reporting permissions are already in use. When a client leaves, review those connections and access rights so the correct people retain control of their own account.
Decide who will check account connections and respond to unexpected traffic or customer complaints. In a small business, that may be the person already managing campaigns. In an agency, assign responsibility for each client. Keep the routine manageable: look for connection problems, review unusual changes and follow up on any unresolved visit or rule.
Leave a short handover note with the installation location, connected account IDs, important exceptions and where reports are kept. Include the steps to check after a website redesign, new checkout or staff change. If a customer cannot use a form, the next person should know where to look and whom to contact. Record why you changed a setting, especially when allowing an exception. That explanation is much more useful six months later than a list of addresses with no dates or reasons. Review access when someone joins or leaves the team.
Check the landing pages receiving your paid traffic, rather than testing only the homepage. Confirm that the tracking snippet is installed through your chosen website or tag-manager setup and has not been added twice. If a campaign sends visitors through a redirect or onto a separate landing-page service, include that destination in the check.
Open a page in your own browser, move to the next step and look for the expected visit record. Test the form or checkout as a customer would. If your site changes pages without a full reload, check those route changes too. Review how the snippet behaves with your consent settings and ask the person managing your website to investigate missing records. Give them the affected URL, approximate time and installation method. After a website redesign or tag-manager change, repeat these checks before relying on the reports from a newly launched campaign.
Suppose a campaign suddenly receives more clicks without more enquiries. Before investigating, you only know that costs have risen. Pausing the campaign may stop the spending, but it can also stop genuine customers reaching you. Start by noting the affected dates and checking whether you changed the budget, targeting, offer or landing page around that time.
Next, inspect the traffic source and a few visits from the affected period. Test the enquiry form yourself. If you find a page problem, repair it. If a particular group of visits looks suspicious, review the available protection settings for that campaign and record the change you make. Afterwards, watch both the suspicious activity and genuine enquiries. This before-and-after example shows how to narrow the response. To assess your own result, compare similar days and keep other campaign changes in the record so you can see what helped.
A real customer might browse through a company network, use a VPN or switch from Wi-Fi to mobile data. Several people can also share one public IP address. These situations matter when you review repeated visits or a network-based flag. If you tighten a rule, check a sample of the affected visits and confirm that ordinary enquiries or purchases still work.
When someone reports a problem, ask which page they tried to use and approximately when it happened. Compare that information with the visit record before changing a broad account setting. Check whether an exclusion or website rule caused the problem, then adjust the relevant setting if needed. Keep a note explaining any exception so the next person managing the account understands it. Include staff, your agency and tools your website relies on in your checks, especially after installing protection or changing a site's forms and checkout.
Start with the problem you are trying to solve. If you manage advertising campaigns, you may want to inspect paid visits and use the account actions available for those campaigns. If bots are overwhelming a form or application, your website team may also need controls at those endpoints. If you are building a platform, you might want risk information that your developers can use inside it.
These needs lead to different purchasing questions. A marketer can try a dashboard and judge whether it helps explain suspicious visits. A developer evaluating an API needs documentation, a way to handle failures and time to maintain the integration. A publisher reviewing advertising inventory may need another type of reporting entirely. Describe your own situation when speaking to a provider: the affected website, source of traffic and action you need to take. That makes it easier to establish whether the product can solve the problem before you compare prices.
Start your report with the campaign, dates and question you investigated. For example: enquiries fell after a new placement started sending traffic. Show the change in spend and qualified enquiries, then add a few visits that explain why you investigated that source. Include the action taken and any question that still needs an answer.
If the report goes to a client, explain unfamiliar terms the first time you use them. They should be able to see what happened without interpreting a list of IP addresses. Keep the detailed records available for the person checking the account. Where a change has been made, say when you will review its effect and what you will compare. A short report with a specific follow-up is easier to use in a campaign meeting than a long list of blocked visits with no explanation of how customers or advertising costs were affected.
Tell us which website and advertising platform are affected, what you expected to happen and what you saw instead. Include when the issue started and whether anything changed shortly beforehand, such as a new landing page, tag-manager update or account permission. A missing visit, a disconnected account and an unexpected flag need different checks.
For a particular visit, include its approximate time and the relevant record details. For an installation problem, provide the affected page and how the snippet was added. Remove passwords, payment details and unnecessary personal information from screenshots. If support needs more sensitive records, ask how to share them appropriately. When you receive a suggested change, confirm which account or page it applies to and what result to check afterwards. Keeping the conversation tied to one reproducible example usually makes troubleshooting easier than sending a large export without explaining the problem you want solved.
Start with a website whose campaigns and customer journey you know well. Confirm that visits are recorded, the correct advertising account is connected and forms or checkout still work. Review a few records with the person who will manage that site. Write down the installation steps and any questions you had to resolve.
Use those notes when adding the next website, but check its own requirements. A shop, a booking site and a lead-generation page may use different domains, forms and tracking tools. Confirm the account IDs and conversion steps for each one. If a site needs an exception, record why rather than adding it to every account. Keep a way to reverse a change if genuine visitors encounter a problem. After each installation, check the first records and connection status before moving on. This makes it easier to find mistakes while the details of that setup are still fresh.
