Case Study / Google Apps Script
How I Built a Private Social Performance Tracking System for Mozi Media
A privacy-safe case study on how I built a Google Apps Script tracking system for Mozi Media to turn social, MQL, and platform data into executive reporting workflows.
I built a private social performance tracking method for the Mozi Media team at Acquisition.com, supporting reporting around Sharran Srivatsaa, Alex Hormozi, and Leila Hormozi. I am keeping the private parts private: no sheet IDs, no internal links, no raw metrics, no credential details, and no confidential operating data.
The public lesson is still useful. The dashboard acted as an operating system for turning scattered performance data into decision-ready reporting.
The problem was the kind of reporting problem many media, marketing, and growth teams eventually hit. Data comes in by person, by platform, by period, and by metric. The team needs weekly visibility, monthly context, quarterly movement, and executive-level summaries without rebuilding the same report by hand every time.
I built the system in Google Apps Script because the source of truth already lived close to Google Sheets. That mattered. I did not need to force the team into a new tool just to prove a technical point. I could meet the workflow where it already existed and build a cleaner layer on top.
The backend reads the source data, normalizes it, and returns a structured data object the dashboard can use. It separates weekly, monthly, quarterly, platform-level, and aggregate views so the interface is not guessing what the numbers mean.
A big part of the work was mapping inconsistent source structures into one consistent reporting model. That is the unglamorous part of automation most people skip. If the data model is weak, the dashboard becomes decoration. If the data model is strong, the dashboard becomes an operating tool.
I added caching so the dashboard does not need to rebuild everything on every normal load. I also included refresh controls and warnings so the system can tell the operator when something needs attention instead of silently failing.
The frontend gives the team multiple ways to look at the same operating reality. I built a quick view for fast movement checks, a detailed view for deeper analysis, an executive snapshot for leadership reporting, and a dedicated MQL view for demand-generation visibility.
The filters matter because different questions need different cuts of the data. I can look by person, by platform, by period, or by broader channel grouping. That makes the dashboard useful for both strategic review and tactical diagnosis.
I also built charting and comparison logic so the system can show movement over time instead of only showing isolated numbers. A number by itself is usually not enough. The useful question is whether it improved, declined, accelerated, stalled, or shifted because of a specific channel.
The system includes export workflows for PDF and slide-style reporting. That is important because dashboards are not always the final destination. Sometimes the output needs to become a meeting artifact, a leadership update, or a follow-up report.
I added an AI summary layer, but I treated it as a reporting assistant, not the source of truth. The system prepares the structured context first, then the AI layer can help turn the numbers into a readable executive summary.
The API key is handled through script properties rather than being hardcoded into the interface. That is the correct pattern for this type of work. Secrets should not live in frontend code, published HTML, or copied dashboard snippets.
I also built fallback behavior because AI features should not break the reporting workflow. If the model is unavailable, returns something unusable, or fails because of a configuration issue, the dashboard still needs to work.
This is the difference between an AI demo and an AI-enabled business workflow. The demo says, 'Look, AI can summarize this.' The workflow says, 'The data is structured, the logic is controlled, the output is useful, and the team can still operate when the AI layer is not available.'
The useful work was deciding what the system should protect the team from: manual copying, unclear period comparisons, inconsistent platform views, repeated report formatting, and fragile executive updates.
For businesses, this is where AI consulting should go. I start by finding where the business repeatedly translates messy work into decisions, then build the workflow that makes that translation faster, cleaner, and more reliable.
A media team needs this because the speed of content can hide the quality of operations. If reporting is slow, scattered, or inconsistent, leadership cannot see what is actually moving. A good tracking system turns performance into a shared language.
I would apply the same pattern to any business with recurring performance reviews: agencies, clinics, sales teams, education businesses, ecommerce teams, recruiting teams, and internal operations departments. The tools may change, but the operating principle stays the same.
First, I map the real workflow. Second, I define the data model. Third, I build the dashboard and controls. Fourth, I add automation, export, and AI only where they make the process easier to run.
That is what I built here: a private, practical reporting workflow that helps a team move from raw performance data to clearer decisions without exposing sensitive information or depending on manual reporting every week.