A-91%
Quality Score
2
Pages
32
Issues
7.9
Avg Confidence
8.4
Avg Priority
17 Critical11 High4 Medium
>_ Testers.AI
AI Analysis
General Pants scored A- (91%) with 32 issues across 7 tested pages, ranking #4 of 14 US retail sites. That's 73 fewer than the 105.1 category average (71st percentile).
Top issues to fix immediately: "Critical Data Loading Failure - Shop and Settings Data Not Available" — Investigate and restore the failed API endpoints that provide shop and settings data; "Critical: Shop data fetch failure prevents core functionality" — Investigate the shop data API endpoint configuration; "Critical: Settings data fetch failure breaks app configuration" — 1) Fix the settings API endpoint DNS/connectivity issue.
Weakest area — accessibility (5/10): Limited alt text visible, and color contrast in some areas may challenge users with color blindness.
Quick wins: Consolidate multiple promotional sections to reduce visual clutter and improve scanning efficiency. Enhance alt text on all product images for screen reader users.
Qualitative Quality
General Pants
Category Avg
Best in Category
Pages Tested · 2 screenshots
Homepage
generalpants.com.au
Detected Issues · 32 total
1
User Tracking Identifier and Device Fingerprinting Data Exposed in Console Logs
CRIT P9
Prompt to Fix
Remove all sensitive user tracking identifiers and device fingerprinting data from browser console logs in the RAD Shopify analytics integration. Specifically: (1) Do not log the clientId UUID or ranMid values to console; (2) Remove the complete navigator object from console output - never log userAgent, cookieEnabled status, or language data together as this enables device fingerprinting; (3) Remove window/screen dimension logging (innerHeight, innerWidth, screen.height, screen.width) which contributes to fingerprinting vectors; (4) Remove tracking configuration settings like serverPixelEnabled and loggingEnabled from console logs; (5) Implement server-side only logging for these sensitive identifiers where they cannot be accessed by users or monitoring tools; (6) Ensure production builds have analytics logging disabled in console entirely, with logging only available in development environments behind explicit developer flags. This prevents privacy-sensitive tracking data from being exposed in user-accessible browser consoles.
Why it's a bug
The console logs expose sensitive tracking and device fingerprinting data that enables user profiling and cross-site tracking. Specifically: (1) clientId UUID '3b1ba746-242c-49e1-9913-02b249e87580' uniquely identifies individual users and persists across sessions; (2) Complete navigator object including userAgent, language, and cookieEnabled status enables device fingerprinting; (3) Detailed window/screen dimensions (800x600 resolution, specific pixel offsets) contribute to fingerprinting; (4) ranMid identifier '42567' suggests internal user tracking; (5) serverPixelEnabled setting indicates server-side tracking activation. This data exposure violates privacy regulations (GDPR, CCPA) and enables unauthorized user profiling and behavioral tracking across the web.
Why it might not be a bug
Some may argue this is standard analytics logging, but logging complete UUIDs, device fingerprinting vectors, and tracking configuration settings to the browser console is excessive and unnecessary. This data should never be visible in client-side logs where it can be intercepted or misused.
Suggested Fix
Remove all sensitive identifiers and device fingerprinting data from console logs. Specifically: (1) Never log clientId or ranMid UUIDs to console; (2) Remove complete navigator object logging - only log essential non-identifying data if necessary; (3) Remove window/screen dimension logging that contributes to fingerprinting; (4) Remove or obfuscate tracking configuration settings (serverPixelEnabled, loggingEnabled); (5) Implement server-side only logging for sensitive tracking data; (6) Use environment-based logging levels to ensure sensitive data only logs in development with explicit developer override, not in production.
Why Fix
Exposing tracking identifiers and device fingerprinting data in browser console logs creates multiple privacy and security risks: (1) Enables user identification and profiling across sessions and websites; (2) Violates GDPR Article 32 data minimization requirements; (3) Breaches user consent expectations for tracking; (4) Creates forensic trail of sensitive identifiers that could be logged by monitoring tools; (5) Compromises user privacy and trust in the platform.
Route To
Privacy Engineer / Security Engineer / Analytics Team Lead
Page
Tester
Pete · Privacy Console Log AnalyzerTechnical Evidence
Console:
[LOG] RAD Shopify app - page_viewed event. Setting: {"loggingEnabled":"true","serverPixelEnabled":"true","useShopifyItemLevelTax":"true","ranMid":"42567"} ... "clientId":"3b1ba746-242c-49e1-9913-02b249e87580" ... "navigator":{"language":"en-US","cookieEnabled":true,"languages":["en-US","en"],"userAgent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64)"} ... "screen":{"height":600,"width":800}Network:
RAD Shopify analytics pixel events being transmitted with exposed identifiers2
Critical: Shop data fetch failure prevents core functionality
CRIT P10
Prompt to Fix
Fix the following error: 'Failed to load resource: net::ERR_NAME_NOT_RESOLVED' when fetching shop data. The application logs show '[LOG] Shop data couldn't be fetched.' This indicates the shop data API endpoint cannot be resolved via DNS or is unreachable. Check: 1) Verify the shop data API domain/URL is correctly configured in environment variables, 2) Confirm DNS records for the shop API are properly set up, 3) Test API endpoint connectivity from the server, 4) Check if the service is running and accepting connections, 5) Add error handling to gracefully display a user-friendly error message when shop data fails to load.
Why it's a bug
Shop data is failing to load with ERR_NAME_NOT_RESOLVED errors, which prevents the storefront from displaying product information. This is a critical blocker that directly impacts user ability to browse and purchase items.
Why it might not be a bug
Could be a temporary DNS resolution issue, but the repeated nature and log message 'Shop data couldn't be fetched' indicates a systemic problem affecting the core user experience.
Suggested Fix
Investigate the shop data API endpoint configuration. Verify DNS resolution for the shop data service, check that the correct API domain is configured, and ensure the service is operational and accessible.
Why Fix
Without shop data, users cannot view products, prices, or inventory - breaking the fundamental purpose of the e-commerce platform.
Route To
Backend/Infrastructure Engineer
Page
Tester
Sharon · Security TesterTechnical Evidence
Console:
[ERROR] Failed to load resource: net::ERR_NAME_NOT_RESOLVED
[LOG] Shop data couldn't be fetched.Network:
Shop data API endpoint - ERR_NAME_NOT_RESOLVED3
Critical: Settings data fetch failure breaks app configuration
CRIT P10
Prompt to Fix
Fix the error: 'Cannot destructure property 'settings' of '(intermediate value)' as it is null' in timesact.js at line 501. This is caused by '[ERROR] Failed to load resource: net::ERR_NAME_NOT_RESOLVED' when fetching settings. Solution: 1) Verify the settings API endpoint URL is correct and DNS-resolvable, 2) In the code that destructures settings, add a null check: if (!settingsData) { use default settings }, 3) Wrap the destructuring in a try-catch block, 4) Implement a fallback configuration object with default settings values, 5) Test that the app gracefully handles missing settings data.
Why it's a bug
Settings data is failing to load with multiple ERR_NAME_NOT_RESOLVED errors and a subsequent JavaScript error trying to destructure null settings. This prevents proper app initialization and causes runtime exceptions.
Why it might not be a bug
Could be a transient network issue, but combined with the destructuring error, this indicates a systemic failure in settings initialization that will crash dependent functionality.
Suggested Fix
1) Fix the settings API endpoint DNS/connectivity issue. 2) Add null-safe checks before destructuring settings object. 3) Implement fallback default settings when API fails. 4) Add error boundary to prevent app crashes from missing settings.
Why Fix
Missing settings prevents the application from initializing properly and causes JavaScript exceptions, making the app non-functional.
Route To
Backend/Infrastructure Engineer and Frontend Engineer
Page
Tester
Sharon · Security TesterTechnical Evidence
Console:
[ERROR] Failed to load resource: net::ERR_NAME_NOT_RESOLVED
[LOG] Settings data couldn't be fetched.
[WARN] jQuery.Deferred exception: Cannot destructure property 'settings' of '(intermediate value)' as it is null.Network:
Settings API endpoint - ERR_NAME_NOT_RESOLVED