B-80%
Quality Score
7
Pages
127
Issues
7.8
Avg Confidence
7.7
Avg Priority
48 Critical50 High29 Medium
>_ Testers.AI
AI Analysis
Playertradehub was tested and 127 issues were detected across the site. The most critical finding was: Geolocation lookup to ipapi.co leaks user IP to third-party without explicit consent. Issues span Security, Performance, A11y, Other categories. Persona feedback rated Visual highest (7/10) and Accessibility lowest (5/10).
Qualitative Quality
Playertradehub
Category Avg
Best in Category
Pages Tested · 7 screenshots
Homepage
www.playertradehub.com
www.playertradehub.com
www.playertradehub.com
www.playertradehub.com
www.playertradehub.com
www.playertradehub.com
Detected Issues · 127 total
1
Geolocation lookup to ipapi.co leaks user IP to third-party without explicit consent
CRIT P9
Prompt to Fix
In the client code, remove the unconditional GET to https://ipapi.co/json/ or gate it behind an explicit user consent flag. If geolocation is required, implement a privacy-preserving flow: (1) replace external geolocation call with a first-party backend service that requests geolocation data only after user consent; (2) ensure IP addresses are anonymized (e.g., strip last octet) before forwarding; (3) add clear consent UI and privacy notice; (4) consider enabling Do Not Track and IP anonymization in analytics as well.
Why it's a bug
A GET to ipapi.co/json/ transmits the user's IP address to a third-party geolocation service. There is no visible consent prompt or privacy disclosure in the observed traffic, constituting unnecessary third-party data sharing and potential regulatory non-compliance for location data.
Why it might not be a bug
Geolocation might be required for certain features; if so, consent should be obtained and data minimized. Without consent, this is a privacy violation.
Suggested Fix
Remove unconditional geolocation API call. If location data is required, implement explicit user consent (e.g., consent banner) and proxy the call through a first-party backend with IP anonymization or use a privacy-preserving geolocation approach that does not transmit raw IP data. Consider using a self-hosted or consent-managed geolocation service and minimize data exposure.
Why Fix
Protects user privacy, reduces third-party data sharing, and helps comply with GDPR/CCPA or equivalent.
Route To
Privacy Engineer / Backend Engineer
Page
Tester
Pete · Privacy Networking Analyzer
Technical Evidence
Console:
GET https://ipapi.co/json/ - Status: N/ANetwork:
GET https://ipapi.co/json/2
Unconsented third-party analytics tracking via PostHog on marketplace pages
CRIT P9
Prompt to Fix
Action: Implement consent-gated analytics. Steps: 1) Add a visible cookie/consent banner that includes an explicit opt-in for analytics. 2) Do not load any PostHog or other third-party analytics scripts until consent is granted. 3) After consent, initialize analytics with privacy protections: enable data minimization, disable autocapture by default, anonymize IP addresses, and respect Do Not Track. 4) Ensure all events sent to the analytics provider exclude PII (names, emails, identifiers). 5) Provide a privacy policy section detailing what data is collected and how it is used. 6) Audit and remove any unnecessary third-party data sharing if not essential.
Why it's a bug
The network activity shows loading of PostHog analytics assets from a third-party domain (eu-assets.i.posthog.com) including dead-click autocapture and other analytics scripts. There is no visible user consent indicator in the logs, and these scripts can capture user interactions and telemetry that are transmitted to an external analytics provider, creating a privacy risk and potential regulatory non-compliance.
Why it might not be a bug
If the site implements explicit consent for analytics (cookie banner, opt-in controls) and respects user preferences (e.g., Do Not Track, opt-out), then third-party analytics usage could be compliant. The provided data does not show consent indicators, so it cannot be assumed compliant from the logs alone.
Suggested Fix
Introduce explicit user consent for analytics before loading any third-party tracking scripts. Delay loading PostHog assets until consent is granted. Enable data minimization (disable autocapture by default), anonymize IP where possible, and respect Do Not Track. Provide a clear privacy notice describing what is tracked and give users a straightforward opt-out mechanism. Review all analytics calls to ensure no PII is being captured or transmitted.
Why Fix
Implementing consent-based analytics minimizes privacy risk, aligns with GDPR/CCPA requirements, and helps maintain user trust and regulatory compliance.
Route To
Privacy Engineer
Page
Tester
Pete · Privacy Networking Analyzer
Technical Evidence
Network:
https://eu-assets.i.posthog.com/array/phc_MmFoYHocgovsVpYWvkrqB0oI6xgKqAkwc4zWIUfCdRi/config.js3
Third-party analytics calls (PostHog) loaded without explicit user consent leading to cross-site tracking
CRIT P9
Prompt to Fix
Implement consent gating for analytics: do not load PostHog scripts on initial page load. Show a privacy/cookie banner with an explicit 'Agree to analytics' option. Upon agreement, dynamically load and initialize PostHog with privacy-friendly settings (e.g., IP anonymization, no PII transmission, first-party hosting or restricted cross-site tracking). Ensure SSR pages do not preload analytics. Update the code to use a client-side only integration after consent and include a clear privacy notice explaining what data is collected and how it is used.
Why it's a bug
The network activity shows loading of PostHog analytics scripts (dead-clicks-autocapture.js, web-vitals.js, surveys.js, and config.js) from a third-party domain (eu-assets.i.posthog.com). There is no evidence of an explicit user consent flow gating these requests in the observed data. This enables cross-site tracking and data collection by a third party, which can violate user privacy expectations and regulatory requirements.
Why it might not be a bug
If a consent mechanism is implemented elsewhere in the app (cookie banner, CMP) and data collection complies with applicable privacy laws, this may not be a bug. However, the provided network logs do not show any consent gating for these analytics requests, so the issue remains until consent is confirmed.
Suggested Fix
Implement consent-gated loading of analytics. Do not load PostHog scripts until the user has explicitly opted in. Prefer first-party analytics or ensure analytics are loaded only after consent. Configure analytics to minimize data collection (disable capturing of PII, anonymize IPs, and avoid sending sensitive attributes). Consider hosting analytics on a first-party domain or using a privacy-friendly analytics provider with clear consent prompts. Ensure Do Not Track respect, and set SameSite cookies where applicable.
Why Fix
Protect user privacy, comply with GDPR/CCPA and similar regulations, and preserve user trust by ensuring analytics are only active with consent and with minimized data exposure.
Route To
Privacy Engineer / Frontend Engineer
Page
Tester
Pete · Privacy Networking Analyzer
Technical Evidence
Console:
Analytics scripts loaded from PostHog domain (dead-clicks-autocapture.js, web-vitals.js, surveys.js, config.js) with no visible consent gating observed in the logs.Network:
GET https://eu-assets.i.posthog.com/static/dead-clicks-autocapture.js?v=1.356.1; GET https://eu-assets.i.posthog.com/static/web-vitals.js?v=1.356.1; GET https://eu-assets.i.posthog.com/static/surveys.js?v=1.356.1; GET https://eu-assets.i.posthog.com/array/phc_MmFoYHocgovsVpYWvkrqB0oI6xgKqAkwc4zWIUfCdRi/config.js; GET https://eu-assets.i.posthog.com/static/dead-clicks-autocapture.js?v=1.356.1