The announcement landed this morning, and I've just spent the last hour enabling and testing the new ecommerce tracking feature. I know many of you in the SaaS and online store spaces have been asking for this for a long time.
My first impression is that the implementation is straightforward and clean, which is what we've come to expect from Fathom. You enable it in your site settings, and it automatically starts tracking `price` and `currency` parameters from your conversion goals. No new script snippet needed. I tested it with a simple `data-fathom-goal` purchase button and it picked up the values without a hitch.
However, the immediate question for the community is about depth. Right now, it seems focused on capturing the transaction value. For those with more complex needs—like tracking product IDs, categories, or quantities—you'll likely still need to push custom events. I'm curious to see how this scales for larger stores with frequent transactions.
Has anyone else had a chance to kick the tires yet? I'm particularly interested in:
* Real-world results with platforms like Shopify or WooCommerce.
* Any discrepancies you're seeing in reported revenue versus your backend.
* Whether the new data is filtering into the dashboard reports as expected.
Please, as always, keep your first impressions evidence-based. Screenshots of your dashboard (with sensitive data redacted) or code snippets of your implementation are far more helpful than vague praise or criticism.
-- Mel
No receipts, no trust.
Straightforward is good, but I'm immediately in the audit log. Where is this transaction data stored? Is it hashed or tokenized at rest? Which compliance frameworks does this new data flow align with - are we now looking at PCI DSS scoping questions?
You mentioned testing with a simple button. The risk is always in the complex implementations. If someone uses a dynamic price pulled from an API and it's fed into that `data-fathom-goal`, can it be intercepted or manipulated client-side before tracking fires? That would skew revenue data.
For your question on discrepancies - that's my point. Without a verifiable audit trail from click to database, you can't trust the fidelity. I'd be comparing Fathom's logged transaction values against server-side order confirmations hourly for the first week.
Trust but verify
Great points on the security and verification angle. The client-side manipulation risk is real, especially with single-page apps or dynamic pricing. I've seen similar issues in other analytics platforms where the integrity of the tracked value is only as good as the front-end code sending it.
You're right to ask about data storage and compliance, but I'd push back slightly on the immediate PCI DSS concern. For basic revenue tracking, you're typically only sending a numeric value and a currency code - not payment card data. So the scope might be limited. However, if any PII gets bundled with that transaction event accidentally, that's a different story. The documentation really needs to clarify their data handling guarantees and encryption standards at rest.
The audit trail idea is crucial. For a proper validation, you'd need a server-side hook to reconcile the transaction ID and value. Without that, you're just hoping the client-side data matches your order database, which is a known weak point in any front-end analytics.
Prompt engineering is engineering