Oracclum Post | Fabio Rezende

Overview

Role: Founder & Software Engineer
Scope: Product, frontend, backend, infrastructure
Timeline: Apr 2024 - Jun 2026

Oracclum was a campaign tracking, attribution, and funnel analytics platform for digital marketing teams. It helped marketers connect advertising clicks to funnel activity and purchases, understand which campaigns, sites, and ads were producing results, and identify where potential customers stopped progressing.

Highlights

Validated the opportunity through interviews with more than ten digital marketing professionals and brought two beta customers into the product before its initial launch.
Built the first version end to end, including customer-side tracking scripts, Node.js ingestion and query APIs, DynamoDB storage, and a React dashboard showing sales attribution by campaign, advertising site, and individual ad.
Expanded the product from basic click-to-purchase attribution into funnel analytics after customers asked to understand where visitors were abandoning their journeys.
Diagnosed and replaced an overloaded ingestion path that was processing only around 80% of peak traffic, rebuilding it around Go, AWS SQS, asynchronous workers, and batched MySQL writes. Eliminated production data loss during traffic peaks and validated throughput above 870,000 events per minute in controlled load tests.

Context

Oracclum began with a recurring problem I saw among digital marketing professionals: paid campaigns were generating traffic and sales, but the connection between those outcomes was often unclear. Marketers could see advertising metrics in one platform and purchases in another, yet they could not reliably determine which campaign, site, or ad had contributed to each sale.

Without that connection, campaign optimization depended on assumptions based on the manual analysis of incomplete signals. A campaign might appear to perform well because it generated clicks, while the traffic it attracted failed to progress through the funnel. At the same time, a valuable campaign could be underestimated because its purchases were not correctly attributed to the original advertising clicks.

Before building the product, I researched the broader market and interviewed more than ten digital marketing professionals from my network. Existing attribution tools could solve parts of the problem, but they were often expensive, difficult to implement, and offered limited support. As a result, marketers without strong technical knowledge could struggle not only to adopt those tools, but also to know whether their tracking was working correctly.

Those conversations shaped the initial scope of Oracclum and helped me secure two beta users before the first version launched. The opportunity was not to begin with the most comprehensive attribution system possible. It was to create a practical product that made reliable campaign attribution easier to install, understand, and use—and to support customers closely enough that they could turn the resulting data into better campaign decisions.

What I Built

I built the first version of Oracclum as a focused MVP for Taboola campaigns. Customers added a tracking script to the pages in their sales funnels ensuring click id would be forwarded through steps and completed purchases would be connected back to their traffic source.

I developed the entire initial product end to end. It included the customer-side tracking script, Node.js APIs for receiving and querying campaign events, DynamoDB storage, and a React dashboard for exploring attribution data. From the dashboard, marketers could review campaign-level results and open individual campaigns to compare performance across the publishing sites and ads responsible for generating traffic.

The first version answered the product’s original question: which campaigns, sites, and ads were producing sales? Once the beta customers began using it, however, they identified an equally important limitation. Knowing where a purchase came from was valuable, but it did not explain what was happening to all the visitors who clicked an ad and never completed the purchase.

In response, I expanded the tracking model to capture the steps visitors reached throughout each customer’s funnel. The reporting interface evolved to show how traffic progressed from the initial advertising click through landing pages, checkout interactions, and purchase events. Instead of seeing only the final number of sales, customers could identify the pages or transitions where the largest percentage of visitors stopped progressing.

This changed Oracclum from a straightforward attribution dashboard into a broader campaign diagnostic tool. Customers could evaluate not only which traffic sources generated results, but also whether problems inside their own funnels were limiting campaign performance. In real use, this visibility helped uncover issues such as a slow-loading page that caused visitors to abandon the funnel and an incorrect product prices that prevented otherwise interested customers from completing purchases.

Technical Evolution

The first architecture was intentionally optimized for learning rather than scale. A Node.js API received campaign events and stored them in DynamoDB, while a separate API queried that data for the React dashboard. This allowed me to release the MVP quickly, validate the tracking model with real users, and avoid investing in infrastructure before I understood which parts of the product customers actually valued.

The first limitation appeared in reporting. As customers accumulated more campaign data and selected larger date ranges, some dashboard queries took more than 20 seconds or timed out entirely. DynamoDB worked well for receiving the original event records, but the access patterns required by campaign and funnel analysis were becoming increasingly difficult to serve efficiently.

I introduced a processing layer that transformed the useful event data into an indexed MySQL reporting model designed around the queries the dashboard needed to perform. This separated the original event capture from analytical reads and reduced campaign-page load times from more than 20 seconds—or complete timeouts—to no more than 3 seconds.

A more serious problem emerged as customers increased their advertising volume. During traffic peaks, events began taking too long to register, some were lost, and purchases could no longer always be connected to the advertising clicks that had generated them. Because the attribution chain depended on receiving every relevant funnel event, even a small amount of data loss could undermine the product’s main promise.

I investigated the bottleneck by monitoring the AWS instance, examining its exhausted burstable compute credits, and recreating the production environment separately for controlled load testing. The tests showed that the existing Node.js ingestion path could process only around 80% of peak traffic.

I rebuilt that path around a concurrent Go ingestion service and AWS SQS. The new API received, validated, and enriched incoming events before placing them on the queue. Go-based Lambda workers then consumed batches asynchronously and performed batched writes to the indexed MySQL model used for attribution and reporting. The queue absorbed traffic spikes and separated request handling from database writes, while batching reduced the amount of work required across the pipeline.

The new architecture eliminated production data loss during peaks of approximately 18,000 to 25,000 events per minute. In controlled load tests, it processed more than 870,000 events per minute, and replacing DynamoDB in the ingestion path with SQS reduced infrastructure costs by at least 10%.

Reliability also depended on what happened outside Oracclum’s infrastructure. Customers frequently changed funnel pages, buttons, and checkout flows without realizing that those changes had interrupted the tracking sequence. Because the breakage was often silent, the first visible symptom might be missing attribution data, leaving me to investigate each integration manually.

To make that process self-service, I built an in-app integration test that reproduced the path of a real visitor. Oracclum generated a campaign URL containing test tracking parameters and a unique click ID. The customer opened the URL, progressed manually through the funnel, and completed the expected journey while the application watched for events associated with that ID. The interface then showed which funnel steps had reported successfully and exactly where the tracking sequence had stopped.

Together with more extensive integration tutorials, this allowed customers to validate new installations and audit their funnels after making changes. It reduced silent tracking failures, lowered the amount of dedicated support required for each integration, and gave me more time to return to product and engineering work.

Outcome

Oracclum grew from an idea into a functioning SaaS business with real customers, paid usage, onboarding processes, production infrastructure, and ongoing customer support. At peak commercial usage, the platform served around 15 active client accounts, tracked over 50 campaigns, and captured more than 2.5 million events per day.

The product connected more than 95% of recorded purchase conversions to verified advertising clicks, giving customers a more reliable basis for deciding where to allocate campaign budgets. Documented customer results included a 30% reduction in cost per acquisition and a 90% reduction in the time required to analyze campaign performance. Across its operation, Oracclum tracked more than R$20 million in customer revenue.

The company also became larger than a product I maintained alone. I recruited and led five software engineering interns, established development and deployment workflows, and balanced mentoring and delivery with product decisions, customer onboarding, support, infrastructure management, and production incident response.

Although Oracclum ultimately closed in June 2026, it completed the full journey from problem discovery to an operated commercial product. I identified a recurring customer pain, validated it before development, shipped the first version, converted real usage into product improvements, supported customers directly, and changed the architecture only when observed constraints justified the investment.

The most important outcome was learning to treat product and engineering decisions as part of the same system. Customer feedback shaped what I built, production behavior determined when the architecture needed to change, and operational pressure revealed where better tooling could replace manual support. Oracclum gave me end-to-end responsibility for both the software and the consequences of the decisions behind it.

Public Scope

Here is a sanitized reconstruction of Oracclum's code base, including a Next.js dashboard, Node.js backend API, restored Go ingestion service, tests, demo flows, and architecture documentation covering service boundaries, SQS-based event processing, attribution logic, reliability decisions, and scaling trade-offs.

View repository