The newsroom publishes, the campaign runs, and at the end of the month nobody can still say which piece pulled in a valuable reader and which one only generated clicks. For a data or digital-revenue director at a publisher or an agency this is daily life: media analytics fragments across the analytics platform, the CMS, the ad server and the CRM, and none of those sources knows the full story of a single audience member.
In our experience the problem is rarely a lack of tools; it is almost always the missing layer that ties them into a coherent data model and keeps it alive over time. That is the capability we supply. RITS Group carries real data and Big Data competence (our LLM/AI/data teams), and our engineers have worked on processing large volumes of events in advertising. We bring that to media projects as team augmentation or a dedicated team.
Why is audience data so fragmented today?
Because every tool was built to solve a different problem, and each keeps its own truth about the same person. The analytics platform sees a browser session, the ad server an impression and a click, the CRM a subscriber, and the mobile app emits yet another stream of events. Nobody stitches them together, because stitching is nobody’s actual job.
On top of that sits a market shift: third-party cookies are disappearing and regulation forces consent. A publisher that leaned on external data is left with a gap that only first-party audience telemetry and a solid first-party model can fill.
How do you build an event pipeline and audience telemetry?
The foundation is an event stream: every interaction (a page view, a scroll, a video play, a newsletter sign-up) arrives as an event with a stable schema on a single bus. Here we usually wire up a queuing and stream-processing layer, for instance Kafka for event transport and Flink or Spark Streaming for on-the-fly aggregation.
The data lands in two places at once: a raw layer (a data lake or lakehouse) where nothing is lost, and an analytical model in a warehouse (BigQuery, Snowflake, Redshift) already computed for reporting, so we can change a metric’s definition and recompute the whole history from scratch.
- collection layer - a lightweight server- and client-side event collector, resilient to blockers,
- transport and buffer - an event queue that survives the spike when a big piece goes live,
- stream processing - sessionisation, deduplication, enrichment with context,
- query layer - a warehouse fed in batch and in near real time.
How do you design content-performance dashboards people actually use?
A dashboard that shows page views alone changes no editorial decision. So we start from who looks at it and when, and build a different view for each role (the editor, the writer, the board) grounded in engagement metrics rather than raw traffic: attentive reading time, scroll depth, a piece’s share in acquiring a subscription.
Underneath, we enforce one shared definition of every metric, so that “active reader” means the same thing in the editorial panel and in the advertiser report. We put the presentation layer in a BI tool, or build a dedicated panel when standard BI can’t keep up with the specifics of content.
How do you compute marketing attribution and funnel reports?
This is where the real business value starts. “Where the traffic came from” isn’t enough; you have to connect the touchpoints into one audience path and assign each a share of the effect. We model this in stages:
- last- and first-touch attribution as a starting point and a reference,
- position-based and time-decay attribution once the paths grow longer,
- data-driven attribution that splits credit based on real conversions,
- funnel reports tying campaign, content and revenue (subscription, lead, ad sales).
The key is that marketing attribution runs on the same event model as the rest of the analytics, not in a separate tool with its own truth. Otherwise the digital-revenue director gets two conflicting numbers.
What are churn and engagement models, and why build them?
For a subscription publisher and for an agency, keeping an audience often matters more than the next visit, so on top of the pipeline we place models that predict the risk of leaving and rank audiences by engagement. We usually begin with a readable scoring scheme (RFM, recency and frequency signals) and only reach for machine-learning models estimating churn probability over a time window once the data can carry it. We develop this layer together with RITS Group’s AI competence, where a project matures toward content recommendation. We keep the model out of black-box territory: marketing has to understand why a given reader is flagged as at risk.
How do you reconcile analytics with privacy and consent?
Privacy isn’t an add-on at the end; it is the condition of entry. We build consent into the pipeline itself: an event without a proper basis simply doesn’t reach where it shouldn’t. We integrate the consent-management layer (CMP) with the event stream, separate identifying data from analytical data, and apply pseudonymisation. That way the analytics is ready for a world without third-party cookies: a strong first-party model, server-side measurement and conversion modelling instead of one-to-one tracking.
Why does data quality decide whether people trust the reports?
The finest dashboard loses its point the day someone catches it in an error. So we treat data quality as part of the product: we wire in tests and data contracts, monitor the stream’s freshness and completeness, and document every metric in a catalogue.
- schema contracts - a changed field in a source doesn’t silently break the reports,
- tests and alerts - gaps, duplicates and odd values surface at once, not a week later,
- catalogue and data lineage - you know where every number came from,
- versioned metric definitions - history holds up even after a rule changes.
Which skills do we provide for a media-analytics project?
We shape the team around the specific stage, not “just in case”: early on you need someone to design the data model and the pipeline, later people for the visualisation layer and the models.
- a data engineer building the event pipeline, warehouse and transformations,
- a data architect laying out the model and the quality layer,
- an analyst / BI specialist turning data into dashboards and metric definitions,
- an ML engineer / data scientist owning attribution and churn models,
- a DevOps / platform engineer keeping the cloud processing infrastructure running.
We fill these roles one at a time, or as a whole team when the analytics has to be stood up from scratch.
How do we do it at RITS?
We work as a nearshore partner from Poland, with a real data base inside RITS Group:
- we ground the data layer in the Group’s Big Data and AI competence and in our teams’ experience processing large volumes of advertising events,
- we verify skills before the start and shape the team around the project stage, from pipeline to models,
- we work in a close time zone, so engineers join code reviews without a long ramp-up,
- we join event collection, the warehouse, dashboards and attribution into one maintainable whole.
Most often we deliver this as custom software built by our team and, where data skills need topping up fast, as team augmentation.
Where to start with audience analytics?
Start from one decision you make on instinct today and would like to back with data: which content to promote paid, or which subscriber to save. That question defines which events to collect, which data model to build and which roles to fill first. We covered the differences between engagement models in our article on IT engagement models.
Building audience and content-performance analytics? Let’s talk - we’ll match a team and a data architecture to your newsroom or agency.