Why We Limited Analytics to Our Own Edge Beacon: Inside the Implementation

1. The problem

Third-party analytics tools are quick to introduce, but can add complexity to cookie consent banners and slow page loading. To avoid both, tip.co.jp adopted only its own cookieless, first-party analytics.

2. Design decisions

• Tracking relies solely on an anonymous ID in localStorage and does not issue cookies.
• The beacon stays under 3 KB and uses navigator.sendBeacon so that it does not block page navigation.
• Collected data is written only to Cloudflare D1, with no integration into external CRMs or summarization services.

3. How the receiver works

The Cloudflare Worker that receives this site’s beacons has three main processing steps.

First, it strictly validates the shape of incoming data. The visitor_id must be a string no longer than 64 characters; path and referrer must be no longer than 2,048 characters; and duration and scroll depth must be finite numbers. A request that fails any of these checks is stopped immediately. Data that fails validation never reaches a database write attempt.

Second, it clamps numerical values to safe ranges. Duration is constrained to 0–86,400 seconds, or 24 hours, and scroll depth to 0–100% before storage. This prevents client bugs or malicious input from inserting impossible values such as negative duration or 1,000% scroll depth.

Third, even if a write fails, the beacon sender receives the same response as a successful write. A beacon is a fire-and-forget operation: analytics failures must not affect page rendering or behavior. Database write failures are recorded only in server logs, while the visitor’s browser receives an empty response with status code 204.

4. The database structure

The Cloudflare D1 database contains just two tables: one for anonymous visitor IDs and first and last visit times, and another for individual page-view events, including path, duration, scroll depth, referrer, and timestamp. When the same visitor ID returns, the last visit time is updated rather than creating another first-visit record. The schema has no fields for identifying details such as names or email addresses.

5. What this design gives up and gains

This arrangement meets the internal research goal of understanding what people read while preserving visitor privacy and page speed. It also leaves capabilities out. The minimal setup does not provide advanced personalization based on detailed individual browsing histories, or the segmentation and A/B testing integrations offered by third-party CDPs. For TIP, prioritizing transparent analytics and page speed over those capabilities is an editorial choice.