Common questions
Fix the usual confusion around live events, localhost, test users, privacy, speed, and no-code tools.
Answers to the setup questions founders usually hit
My users are not appearing in the dashboard
The most common reason is that identify() is not being called after login, or it is called with an empty user object. Also make sure you are not on localhost — DropFix mirrors localhost events to the browser console but doesn't store them server-side.
The live event feed shows nothing
Check that the script tag is in the <head> section of the page that actually loads. In browser DevTools' Network tab, look for a request to cdn.jsdelivr.net for the SDK and POSTs to www.dropfix.in/api/v1/track for events. If you see neither, see the next three questions — CSP, ad-blockers, and cookie consent are the usual suspects.
It works in development but the SDK doesn't load in production
Your production app probably has a Content Security Policy that doesn't allow the SDK's CDN. Add these to your CSP header: script-src include https://cdn.jsdelivr.net — connect-src include https://www.dropfix.in. Without these the browser silently refuses to load the SDK and you'll see a CSP error in the console.
Some users see events tracked, others see nothing
Ad-blockers like uBlock Origin and Brave shields sometimes block analytics scripts loaded from jsDelivr. If you want bulletproof delivery, self-host the SDK: copy dist/dropfix.js from the @dropfix/sdk npm package to your own static assets, then change the script src to your domain. The data-key attribute and identify() API stay the same.
How does DropFix handle GDPR / cookie consent in the EU?
The SDK uses localStorage (an anonymous distinct_id, e.g. dropfix:distinct_id) and sessionStorage for session tracking. No third-party cookies, no advertising trackers, no fingerprinting. If you have a cookie-consent gate, only render the <script> tag after the visitor accepts analytics. The recommended pattern is to load the SDK conditionally based on your consent state — do not render the tag until consent fires.
My SDK was working, then suddenly stopped after my deploy
Check Settings → Security → Allowed domains. DropFix uses a per-workspace domain allow-list. Your first production domain is added automatically the first time the SDK sends an event from it — but additional deploy domains (custom subdomains, www vs apex, staging vs prod) need to be added manually. Without them, events are rejected with `domain_not_allowed`. Add new domains BEFORE deploying.
Can my test users pollute the data?
Yes. Add your own user IDs in Settings -> Health Scoring -> Never track these users so DropFix ignores your internal activity.
Will the script slow down my app?
No. The script loads with defer so it never blocks rendering, is around 6 KB gzipped, and sends small background batches every 15 seconds.
Does DropFix see passwords or private messages?
No. DropFix captures button clicks, page views, and form submissions, but never reads field values. Password fields are explicitly skipped.
What if a user is on multiple devices?
As long as identify() uses the same user ID on both devices, activity is combined into one user profile.
What if my user object doesn't have plan or MRR yet?
Pass what you have — plan and mrr are optional. Use 'free' (or 'trial' for trialers) as a fallback for plan and 0 for mrr until you wire up Stripe. DropFix's behavioural signals work without payment data; you'll just be missing the payment-failure cascade until Stripe is connected.
Will marketing page clicks appear in analytics?
DropFix automatically excludes common marketing routes like /pricing, /about, /blog, /signup, and /login. Add custom public routes in Settings -> Health Scoring.
Can I use DropFix with Webflow, Bubble, or no-code tools?
Yes for the script tag. For identify(), your tool needs a way to run JavaScript after login. Email febin@dropfix.in if you need help.