Internal Campaign Tracker: Keeping the Click and Conversion Connected
A conversion report should let you answer three questions: where did this visitor come from, which route did they take, and what happened after they converted?
I built Internal Campaign Tracker for a business partner to connect those steps in one application. The project covers campaign setup, traffic routing, conversion handling and reporting, with an administration interface built around the operator’s daily work.
Keeping the original visit connected
Campaigns can route visitors by country, device, browser and schedule, using weighted or sequential distribution and traffic caps. Each visit retains its original campaign and destination details, so moving from a landing page to an offer preserves that context.
Incoming conversion notifications are matched to the original visit, with duplicate checks to prevent repeated notifications from being counted as separate events.
Country breakdown with report filters and tracking metrics. The screenshot shows the interface, not a claimed campaign result.
Campaign actions remain available from the reporting workspace.
Making failed deliveries recoverable
Sending conversion data to another system introduces another failure point. I built a persistent callback queue with retries, delivery history and replay controls.
An operator can inspect a failed delivery and retry it from the application. The failure remains visible instead of disappearing behind a successful-looking dashboard.
Reporting that supports investigation
The reporting workspace includes filters, multiple breakdowns, configurable columns, saved views and exports. Operators can switch between tables, trees and charts, then access campaign actions directly from the reporting interface.
I separated routing from historical reporting, with bounded reporting jobs that have their own execution limits.
My role and implementation
I built the backend, administration interface, routing logic, conversion processing and reporting workflows. The stack combines Elixir, Phoenix and LiveView, with ETS for routing configuration, RocksDB for operational records, and Parquet/DuckDB for historical reporting.
The result is a working private proof of concept that brings campaign operations and the evidence behind their reports into one workspace. It demonstrates the engineering behind the visible dashboard: preserved visit context, duplicate handling, recoverable callbacks and reusable reports.