A data model out of room
An ad platform open to anyone who ships an App Store app, reporting on questions its advertisers had stopped asking.
- Client
- Apple
- Via
- Advantis Global
- Sector
- App Store advertising
- Role
- Software engineer, contract
- Year
- 2022-2023
- Result
- Analytics rebuilt
The problem
Anyone who ships an app to the App Store can run campaigns on it, which means the platform serves a developer with one app and a team managing a portfolio of them, through the same reporting.
The analytics module answered the questions it had been designed around years earlier. Advertisers had moved on to different ones, and the data model had no room left to hold them. Not slow, not wrong, just shaped for a conversation that had ended. The usual symptom is people exporting everything and rebuilding the answer in a spreadsheet, which is a reporting tool telling you it has stopped being one.
The constraint
Nothing could pause. These are live campaigns with real budgets attached, so reporting going dark is not a maintenance window, it is advertisers flying blind with money moving. The rebuild had to arrive underneath people who never agreed to be part of a migration.
The second constraint was that a framework upgrade was happening at the same time. Core components were moving to Angular 11 while the analytics work ran, which meant the rebuild had to target a platform that was itself in motion, and neither effort could be the reason the other slipped.
What I built
The upgrade, underneath a running platform
Core components moved to Angular 11 without a freeze and without a flag day. The work that makes this possible is unglamorous and mostly consists of refusing to bundle unrelated changes into the same release, so that when something breaks the list of suspects is short.
A model shaped for the questions being asked now
The analytics module rebuilt end to end, starting from what advertisers were actually trying to find out rather than from what the old schema could express. The difference between a reporting tool people trust and one they export out of is usually not the numbers. It is whether the shape of the data matches the shape of the question.
Room for the next question
The failure I had just spent months undoing was a model with no extension path, so the rebuild was designed to take new cuts of the data without another end-to-end rewrite. The test I held it to was simple: could a question nobody had asked yet be answered without starting over.
Result
Angular 11 across the platform's core, delivered without taking campaign management offline.
Reporting reconstructed around current advertiser questions rather than the ones the original schema was built for.
New cuts of the data became an addition rather than another rewrite, which was the actual point of the exercise.
The resume claim for this engagement, that the work boosted business user engagement, was identified as an estimate and is absent. What is claimed here is what shipped and what it was designed to make possible.
What I would change
I upgraded the framework and left the architecture alone. Angular 11 landed, the platform was better for it, and the structural reasons that upgrade was expensive in the first place are all still there waiting for whoever does the next one. I treated the version number as the goal because the version number was the thing on the ticket.
What I would do now is make the architectural work its own named deliverable instead of hoping it rides along inside an upgrade. "Upgrade to v11" gets approved on sight; "restructure the parts that make upgrades cost this much" needs somebody to make the case, and if nobody makes it, the next engineer pays the same tax and it is nobody's fault in particular. Six months was enough time to make that case. I did not make it.
Email me
If you are hiring for a senior full stack or frontend role, a line about the team and the stack is enough to start.