analytics says 41% activation, my own sql says 26% — which one is lying

Third possibility that nobody has said yet: the seven day window. Your SQL probably applies it strictly from signup timestamp. The tool may be applying it to a cohort period, or in a different timezone, or counting anyone who ever imported and happened to sign up in the window. Timezone alone will move a seven day funnel by a few points.

Read the tool's definition of the funnel step order too. Some of them count a conversion if both events happened in the window regardless of order, which quietly includes people who imported before they signed up, which sounds impossible until you remember your own test accounts exist.

The other classic is identity stitching. Anonymous browsing gets one id, signing up creates another, and the tool merges them on identify. If someone signs up on their phone and imports on their laptop, or clears cookies between the two, the tool may count two people where your database counts one. Depending on which side of the join the merge fails, you get either an inflated or deflated funnel.

Check one specific user by hand. Pick five accounts you know completed an import, and find each of them in the analytics tool. Five manual traces will usually show you the mechanism in twenty minutes, which is faster than reasoning about it.

Almost certainly your denominators differ, and the usual culprit is that the analytics tool never saw some of your signups at all.

Browser extensions block requests to known analytics domains, so a percentage of your users simply do not register on the front end. It is not small — routing events through your own domain instead of the vendor's typically recovers something in the region of a tenth to a third of events depending on your audience, and a developer-heavy audience is at the top of that range. If your signups are blocked but your imports are tracked server side, or the other way around, you get exactly this shape of discrepancy.

Fix: send the events that matter from your server, and put a reverse proxy on your own domain in front of the client-side ones. Do not name that subdomain anything containing analytics, tracking, telemetry or the vendor's name, because those get blocked too.

Trust the database. It is the only source that knows what actually happened. Use the analytics tool for shape and direction, never for a number you would put in an email to anyone.

Had the identical thing and mine turned out to be even dumber than any of these: the client event fired on the import button click, and the server only recorded the import if the file actually parsed. About a fifth of imports failed on a malformed file. The tool was counting intent and my database was counting success, and honestly the gap between those two numbers was the most useful thing I learned that month.

Practical policy that ended this argument for me: one metric, one source, written down. Anything that touches money or a decision comes from a SQL query saved in the repo with a comment explaining the definition. Everything else can come from the tool.

It sounds bureaucratic for a one person company and it takes about an hour to set up, but it means you stop rediscovering the same discrepancy every quarter. Also exclude your own accounts and your test emails in the query itself rather than remembering to filter, because you will forget.