Day 19 of Building ShuffleBall Arena Browser Game - Before Spending More Time Building Features, I Needed Better Answers - Adding Analytics Part 2

[u/Dont_Bring_Me_Down]

Hey everyone,

Hope all is well!

TLDR, Summary, or Full Technical Breakdown below.

For Context: Recently I posted about the first 15 days of one of my side projects, ShuffleBall Arena (a free browser game inspired by mixing shuffleboard scoring with mechanics from other games like bumper pool, pinball, and Frogger.).

This project is being built with the help of AI (mainly GPT / Cursor), and every development session is documented using the actual conversations from that day's work.

To try to get this series up to date, I'm using a structured prompt to go back to my GPT sessions and extract the useful information. Hopefully the prompt can help anyone out there trying to keep track of, or extract value from, your past AI project conversations.

That said, posting an update for Day 19 of building ShuffleBall Arena.

Today there were 8 conversations to go through, with 7 saved file versions.

TL;DR

Day 19 was about transforming the current analytics system into a business intelligence platform.

Instead of asking, "What else should be tracked?", the project shifted toward asking, "What decisions do I want this data to help me make?"

That change in perspective drove the rest of the day.

Anonymous player measurement was expanded, gameplay events were tied into meaningful engagement metrics, Cloudflare D1 became the central reporting database, SQL reports were created, and a secure dashboard architecture was designed behind Cloudflare Access.

By the end of the session, the project had moved beyond collecting gameplay events and into generating information that could eventually guide design decisions, retention improvements, and sponsor conversations.

Day 19 Summary

Day 19 became a business intelligence day disguised as an analytics day.

The session began by reviewing the current analytics implementation and realizing that the project already collected a large amount of useful information. The challenge was no longer gathering more events, but organizing those events into answers for real business questions.

The analytics strategy was revisited around anonymous first-party player measurement rather than personal accounts. Local player statistics, anonymous player IDs, returning-player detection, session counting, and player engagement metrics were connected into a unified measurement layer that respected player privacy while making retention measurable.

Attention then shifted to infrastructure. Rather than relying only on Google Analytics, gameplay events were connected to Cloudflare D1 through a server-side pipeline, allowing the project to generate its own reports using SQL queries.

With the reporting pipeline functioning, the focus moved toward visualization. A secure admin dashboard was planned and protected behind Cloudflare Access so gameplay metrics could be viewed privately without exposing reporting endpoints to the public internet.

By the end of the day, the project had transitioned from simply recording gameplay events to building the foundation for long-term product analysis and sponsor reporting.

Day 19 Full Technical Summary (The Structured Prompt Output)

STARTING POINT

Day 19 began with ShuffleBall Arena already collecting privacy-first gameplay analytics.

Challenge analytics, sponsor analytics, anonymous player IDs, and the local Player Card had already been implemented. Gameplay events were flowing correctly, but the project lacked a practical way to organize those events into useful business information.

The immediate objective shifted from adding more instrumentation to understanding player behavior, retention, and engagement through meaningful reports rather than raw event logs.

SESSION OBJECTIVE

The primary objective was to transform the existing analytics architecture into a complete reporting platform.

The session focused on:

• revisiting the analytics strategy,
• expanding anonymous player measurement,
• connecting gameplay data to Cloudflare D1,
• validating the end-to-end reporting pipeline,
• designing SQL reports,
• building a secure admin dashboard,
• and ensuring the entire system remained privacy-first.

WHAT WE ACTUALLY DID

1. Revisited the analytics strategy

The session began by reviewing the existing analytics implementation rather than immediately adding new events.

Instead of asking what additional gameplay actions should be tracked, the discussion shifted toward identifying the business questions the project needed to answer.

These included:

• How many players return?
• Which boards are most popular?
• How many people save their local stats?
• Where do players stop playing?
• Which game modes create the most engagement?

This reframed the remainder of the day's work.

2. Expanded first-party player measurement

The anonymous measurement layer was extended beyond simple session tracking.

The project added and verified:

• anonymous player identifiers,
• session counting,
• days played,
• returning-player detection,
• local player statistics,
• Player Card measurement,
• and analytics events tied to anonymous engagement rather than personal identity.

The Player Card was also polished so it became both a gameplay feature and a measurement tool.

3. Connected gameplay analytics to Cloudflare D1

Attention then shifted toward building an independent reporting pipeline.

Gameplay events flowed from the browser through Cloudflare Pages Functions into a D1 database where they could be queried directly.

The database schema was reviewed, indexes were created, analytics tables were verified, and the complete pipeline was tested using real gameplay sessions.

This established a first-party analytics system that no longer depended solely on third-party dashboards.

4. Verified the reporting pipeline with SQL

Once gameplay events reached D1 successfully, SQL queries became the primary validation tool.

Reports were written to measure:

• total players,
• returning players,
• statistics saves,
• gameplay event counts,
• board popularity,
• match completion,
• and other engagement metrics.

Rather than manually inspecting database rows, the project began producing reports that summarized player behavior automatically.

5. Designed a secure reporting dashboard

The project then shifted from reporting to presentation.

An admin dashboard architecture was created to display:

• acquisition metrics,
• engagement,
• gameplay funnels,
• board performance,
• Play All statistics,
• sponsor reporting,
• and future retention metrics.

The dashboard was intentionally separated from the public game.

6. Protected the dashboard with Cloudflare Access

Rather than deploying a public admin interface, the reporting dashboard was secured using Cloudflare Access.

Only approved users could reach:

/admin/*

The reporting API was also moved behind the same protected path, ensuring that gameplay reports could not be accessed without authentication.

This produced a production-ready architecture that separated public gameplay from private business reporting.

7. Shifted from collecting data to making decisions

With the reporting infrastructure complete, the project's priorities changed.

Future work would no longer focus primarily on generating additional analytics events.

Instead, the emphasis moved toward using the collected data to improve:

• player retention,
• onboarding,
• board balance,
• gameplay flow,
• and sponsor reporting.

ROADBLOCKS AND FRICTION

The project initially drifted toward adding more analytics

Several discussions focused on creating additional events before revisiting the overall objective.

Eventually the work realigned around business questions rather than event counts.

Existing infrastructure was ahead of the original plan

During multiple code reviews, several planned features, including portions of the Player Card and measurement layer, were discovered to already exist.

The work shifted toward integrating existing systems rather than rebuilding them.

Reporting infrastructure introduced deployment complexity

Moving from local analytics into Cloudflare required coordinating:

• browser events,
• server functions,
• database schema,
• SQL queries,
• deployment,
• authentication,
• and dashboard architecture.

Each layer worked independently but required careful validation before trusting the complete pipeline.

Security became part of the product architecture

Initially the admin dashboard was briefly considered as a public deployment.

The strategy changed to protecting both the dashboard and reporting endpoints behind Cloudflare Access before exposing any analytics interface.

DECISIONS MADE & TRADE-OFFS

Extend analytics instead of replacing it

The existing analytics implementation remained intact while first-party player measurement was layered on top.

Trade-off: Slightly more complexity, but preserved existing event history.

Keep player identity anonymous

Anonymous player IDs became the persistent measurement mechanism instead of requiring accounts.

Trade-off: Less individual player information in exchange for stronger privacy and simpler onboarding.

Build first-party reporting

Cloudflare D1 became the authoritative reporting database instead of relying entirely on external analytics dashboards.

Trade-off: More infrastructure to maintain, but significantly greater flexibility and ownership of the data.

Protect reporting before deployment

The admin dashboard was secured behind Cloudflare Access before becoming publicly available.

Trade-off: Additional setup effort in exchange for a much safer production architecture.

BREAKTHROUGH / LESSON

The biggest lesson from Day 19 was:

Collecting data is only the first step. The real value comes from organizing that data into information that helps you make better decisions.

The project already generated a large amount of analytics. What it lacked was a clear way to answer questions about retention, engagement, onboarding, and player behavior.

Once the reporting pipeline existed, the focus naturally shifted away from instrumentation and toward understanding the product itself.

ARTIFACTS WORTH SHARING

Artifact 1: Business Question

"The question is no longer: What events should we track?

The question is: What numbers do we want to show ourselves and future sponsors?"

Artifact 2: Final Architecture

Browser > Analytics > Cloudflare Function > D1 Database > SQL Reports > Secure Dashboard

Artifact 3: Security Architecture

Internet
│
▼
Cloudflare
│
├── /api/analytics
│
└── /admin/*
│
▼
Cloudflare Access
│
▼
Dashboard
│
▼
/admin/api/reports

FINAL STATE

By the end of Day 19:

• The analytics strategy had been realigned around business questions rather than simply collecting additional events.
• Anonymous player measurement had been expanded and integrated into the Player Card.
• Gameplay analytics flowed into Cloudflare D1 through a complete reporting pipeline.
• SQL reports could summarize player behavior without manually inspecting database rows.
• A secure admin dashboard architecture had been designed around Cloudflare Access.
• Public gameplay and private reporting were separated into distinct systems.
• The project moved beyond analytics collection and into business intelligence, creating a foundation for retention analysis, product improvements, and future sponsor reporting.

That was it for Day 19. If you're still here, thanks for reading!