Analytics without surveillance: privacy-respecting measurement for a group of companies

Most analytics setups are built by accretion. A tag here, a pixel there, a session recorder someone tried once, an ad platform's script that came with a plugin. Two years later the site sends data to a dozen places, nobody can list them all, and the business is collecting far more about its visitors than it uses — or could justify if asked.

We take the opposite approach. Analytics without surveillance means measuring what a company needs in order to decide, and not much more. It is not about measuring less for its own sake. It is about measuring deliberately, in aggregate, inside boundaries that customers would recognise as fair.

For a group like ours, one boundary matters above the others. Oryvelon runs several independent companies. A person might read about a Shopify assistant on MerchNivo, book a course at Sinem Keser Beauty Academy and buy a phone case from Noveniq. Those are three separate relationships, and our analytics treats them that way.

Start from decisions, not from data

The most useful question in analytics design is not "what can we track?" but "what will we decide with it?"

For most of our companies, the list of recurring decisions is short:

• Which channels are worth more time or budget?
• Where do people drop out of the path to signing up, buying or booking?
• Do customers come back, renew or buy again?
• Is each product's cost per useful outcome acceptable?
• Did a change we made improve things, make them worse or do nothing?

Every one of those can be answered with aggregate data: counts, rates, trends and cohorts. None requires knowing who a particular visitor is, reconstructing their journey across other websites or recording their mouse movements.

So we start there. Each company's source-of-truth document includes a short measurement plan: the decisions the company makes regularly, the metrics that inform them, and the events needed to produce those metrics. Anything not on the plan is not collected. When someone wants a new event, the first question is which decision it serves.

This has a practical benefit besides privacy. Analytics that nobody uses still costs attention, page weight and review time. A small, deliberate set of events is easier to keep accurate.

One property per company

Every Oryvelon company has its own analytics property, tied to its own domain and owned by the company. oryvelon.com has its own property too, for the group site only.

There is no roll-up property that collects all companies' visitors in one place. There is no shared tracking script with a common identifier. There is no cross-domain measurement configured between brands.

We made this choice for three reasons.

It matches reality. The companies serve different people for different reasons. A visitor to ZodiVela and a visitor to KeşifAtlası are not one audience, and treating them as one would produce misleading averages.

It keeps data where it belongs. A company's analytics data is part of that company, in the same way its customers and content are. If a company were ever separated from the group, its analytics history would go with it, intact and uncontaminated. See Designing every company so it could stand alone.

It makes cross-brand tracking structurally impossible, not just forbidden. A policy that says "don't join users across brands" is weaker than a setup where there is nothing to join. This is the same principle we apply everywhere in the group: shared infrastructure, separate data.

What is shared is the method. Every company uses the same measurement plan template, the same event naming style, the same UTM convention and the same review cadence. Consistency comes from standards, not from pooled data.

Aggregate metrics first

Most of the numbers we look at are aggregates. A few examples of what that looks like per company:

These are counts and rates across many people. They tell us whether something is working without telling us anything about any individual.

Where we need to look at behaviour over time, we use cohorts rather than individual journeys: "of the stores that started a trial in a given week, how many were active four weeks later?" A cohort answers the retention question without anyone reading a person's history.

For product analytics inside logged-in products, the product itself holds its own data under its own rules — orders in the store, readings in ZodiVela, reports in KeşifAtlası. Those numbers are counted from the product's systems, not inferred from a tracking tool. That is more accurate as well as more private. It is the analytics version of our principle that verified data decides.

What the group site measures

oryvelon.com is a useful, concrete example, because it is small and its measurement plan fits in a paragraph.

The group site exists to explain what Oryvelon is and to send people to the right company or the right contact route. So it measures:

• visits by source and medium, to understand how people find the group;
• a company_outbound event when someone clicks through to a company's website, recording the destination without its query string and the link text;
• a contact_email_click event when someone clicks an email address;
• a generate_lead event when the contact form is submitted successfully, recorded on the thank-you page.

That is essentially all. No scroll-depth tracking, no session recording, no heat maps, no advertising pixels. The analytics configuration only runs on the production hostname, so previews and test builds do not pollute the numbers.

The outbound event is a good illustration of the boundary. The group site learns that a click to MerchNivo happened. It does not learn anything about what the visitor did on MerchNivo. MerchNivo, in turn, sees a visit arriving with utm_source=oryvelon and utm_medium=portfolio in its own property. Neither side can connect the two into a person.

Consent, per company and per audience

Consent requirements for analytics depend on where visitors are, what is being collected and how. Laws such as GDPR in Europe and KVKK in Türkiye set expectations, and our companies serve audiences in different places. What follows describes our practice; it is not legal advice, and each company takes its own advice for its own situation.

Our practice has a few consistent elements.

Consent is decided per company. Each company's source of truth records which audiences it serves, which tools it uses and what consent mechanism applies. A company serving a European audience with non-essential analytics cookies needs a consent step; the same decision is not automatically copied to every other company.

Tags respect the choice. Where consent is required, analytics and marketing tags wait for it. Tag configurations that support a consent mode are set so that, without consent, no identifying cookies are set and only what is permitted is sent.

Declining is as easy as accepting. A consent banner that makes "reject" hard to find is not consent. Where we show a choice, both options are equally visible.

Analytics consent is separate from marketing consent, and both are separate from product consent. Agreeing to analytics cookies does not sign anyone up for emails, and agreeing to a product's terms does not imply either. See Marketing consent vs product consent.

Choices are respected across visits and not re-asked constantly. Nagging someone until they accept is not a meaningful choice either.

No cross-brand user tracking

This deserves its own section, because it is the easiest line to cross in a group of companies and the most damaging if crossed.

The temptation is understandable. If one person is a customer of two companies, a group could offer them something relevant, or learn from their combined behaviour. Many conglomerates do exactly that.

We do not, and the rules are specific:

• No shared identifiers. No common user ID, cookie or device identifier across companies' analytics.
• No cross-domain linking. Analytics tools are not configured to stitch sessions across different brands' domains.
• No shared advertising audiences. One company's customers are never uploaded as an audience for another company's ads.
• No shared pixels. Each company's advertising tags belong to that company's own ad accounts, installed only on its own site.
• No data joins. Nobody combines exports from two companies' analytics or customer systems to find overlapping people.

The same boundary appears in our AI systems: the shared AI gateway sees requests from products, not people across products. See Building an AI gateway and Why we don't merge products into one app.

When the group needs a cross-company view — for the monthly portfolio snapshot, for example — each company reports its own aggregate numbers. The portfolio view is a table of totals, not a merged dataset.

What never goes into analytics

Some data does not belong in an analytics tool regardless of consent.

• Personal data in event parameters. No emails, names, phone numbers, addresses, national identifiers, or free-text fields that might contain them. Form contents are never sent as events.
• Personal data in URLs. If a page URL could contain an email or token — a password reset link, a pre-filled form — it is excluded or stripped before analytics sees it.
• Sensitive categories. KeşifAtlası does not send anyone's nationality, visa route or eligibility result to analytics as an attribute of a person; it counts how many tests of each type were completed.
• Children's data. EduRelia is the strictest case. Pages used by students do not carry advertising tags, and analytics on the learning product is limited to aggregate product health.
• Marketplace contact data. On CastLyra, contact details follow access rules inside the marketplace. They never appear in analytics, and profile views are counted without exposing who viewed whom.

A periodic check looks for accidental leaks: someone adds a form field and the tag manager captures it, or a URL parameter starts carrying an email. These are much easier to catch in a small, well-documented setup than in a sprawling one.

Retention and access

Analytics data is still data, so it follows the same basics as everything else.

Retention settings in analytics tools are set to the shortest period that supports the company's decisions — usually long enough for year-over-year comparisons of aggregates, not indefinitely. Raw exports, where they exist, have their own retention rules.

Access follows least privilege. Each company's analytics property is accessible to that company's team and the few people in the group who support it, with two-factor authentication required. Nobody has standing access to every company's analytics by default. Access is reviewed as part of the quarterly tool review, alongside everything else in the tool inventory. See also Least-privilege access for small teams.

A worked example: measuring a funnel change

Suppose KeşifAtlası changes the last step of its free eligibility test. Previously the result page showed a short summary and a button to buy the full report. The new version adds a plain explanation of what the paid report contains and what it does not, including that it is not legal advice. The question is whether the change helps or hurts.

Everything needed to answer that is aggregate:

1. Define the funnel in events. test_started, test_completed, report_viewed, report_purchased. No event carries the person's nationality, answers or result — only the fact that a step happened and, where useful, which test type it was.
2. Compare periods or variants. Either run the old and new versions side by side with a random split, or compare a stable period before and after. The split is cleaner; the before-and-after comparison is simpler for a small company.
3. Read the rates, not the individuals. Completion-to-purchase rate before and after, with the number of completed tests alongside so nobody over-reads a small sample.
4. Check the side effects. Did refund requests or questions routed to people change? Those numbers live in the product and support systems, counted in aggregate.

At no point does anyone need to watch what a particular person did. The decision — keep the new page, revert, or iterate — comes from a handful of rates. The same approach works for MerchNivo's trial onboarding, Noveniq's checkout or ZodiVela's credit purchase flow.

Reading aggregate numbers well

Aggregate data has its own traps, and a privacy-respecting setup does not excuse sloppy interpretation.

Small numbers lie. A new company might see a few dozen conversions a week. A change from 12 to 15 is not a 25% improvement in any meaningful sense; it is noise until it holds for several weeks. We show counts next to every rate so nobody forgets how small the base is.

Incomplete data is biased, not just smaller. When some visitors decline analytics, the ones who remain are not a perfect sample of everyone. Product-side numbers — orders, bookings, reports sold — are complete, so we use them as the reference and treat analytics as the explanation of how people arrived.

Thresholds protect people too. When a segment gets very small — a single school, a rare visa route, one course date — reporting on it can start to describe individuals rather than groups. We avoid breaking aggregates down below a sensible minimum size, especially for EduRelia and KeşifAtlası.

Trends beat snapshots. A single week tells you little. The monthly snapshot compares a rolling window with the previous one, which smooths out most of the noise without hiding real change.

Trade-offs we accept

Being honest about analytics means being honest about what this approach costs.

Less precise attribution. Without cross-site tracking and with some visitors declining consent, attribution is incomplete. We accept wider error bars and look for consistent trends rather than exact figures.

Less ad platform optimisation. Advertising platforms work better with more data. Companies that advertise send conversion signals within their own consent rules, which gives the platforms less to work with than an aggressive setup would. For our companies, the trade is worth it.

No cross-selling from behaviour. We cannot say "customers of this company might like that one" based on what individuals did. If a company wants to reach another company's audience, it does so through public channels, the same as anyone else.

More upfront thinking. Deciding what to measure before building takes longer than installing every tag available. It saves time later.

A practical checklist

• Write down the decisions each company makes regularly, then the metrics and events they need. Collect nothing else.
• Create one analytics property per company and per domain; do not create a group-wide roll-up that tracks people.
• Use the same event naming style and UTM convention across companies so aggregates compare cleanly.
• Configure consent per company and audience; make declining as easy as accepting.
• Keep personal data out of event parameters and URLs.
• Set retention to what decisions need, and review access quarterly with two-factor authentication required.
• Report across the group with aggregate totals, never merged user data.

Summary

Analytics without surveillance means measuring what a business needs to decide and stopping there. Across Oryvelon, every company has its own analytics property on its own domain, measurement plans start from decisions, metrics are aggregate by default, consent is handled per company and audience, and no identifier, pixel, audience or data join links a person across brands. The group site measures little more than visits, outbound clicks and enquiries. We accept less precise attribution in exchange for a setup customers would recognise as fair — and one where crossing the line is not just against the rules but structurally impossible.

Questions and answers

What does analytics without surveillance mean?

It means collecting the aggregate data a business needs to make decisions, such as visits, conversions and retention, without building individual profiles, tracking people across unrelated sites or collecting personal data in analytics tools.

Does Oryvelon track users across its companies?

No. Each company has its own analytics property on its own domain, and no identifier, pixel or data join links a person's activity in one company with their activity in another.

Can privacy-respecting analytics still support growth decisions?

Yes. Channel performance, conversion rates, funnel drop-off, retention cohorts and cost per outcome can all be measured in aggregate, which covers most growth and product decisions.

Published by Oryvelon, a digital company builder · About the group · Our companies · More in Growth, Search & Measurement

NextFounder authority sites: how personal sites relate to a group and its companies →