DEV Community: Zenovay

The 25-hour day in your analytics

Zenovay — Sun, 01 Nov 2026 13:55:31 +0000

Sunday had an extra hour in Switzerland. That matters when you compare daily traffic, not just when you change a clock.

On 25 October 2026, Swiss clocks moved from 03:00 back to 02:00. The local calendar day lasted 25 elapsed hours. A report for that date in UTC covered a different window. Both can be valid, yet their totals need not match.

Before calling a daily increase growth, check what the word “day” means in the report.

One date can describe two different windows

The date 2026-10-25 is not a complete time range. It needs a time zone and boundaries.

For a Europe/Zurich business day, start at local midnight and end at the next local midnight. Convert those two instants to UTC. The offset changes inside this particular interval, so its duration is not 24 hours.

Report definition	Start in UTC, included	End in UTC, excluded	Elapsed hours
25 October in Europe/Zurich	2026-10-24 22:00	2026-10-25 23:00	25
25 October in UTC	2026-10-25 00:00	2026-10-26 00:00	24

A hypothetical event at 2026-10-24T22:30:00Z belongs to 25 October in Zurich and 24 October in UTC. Nothing about the event changed. The reporting boundary did.

The Swiss change is confirmed in the METAS announcement. The table is a worked example of reporting boundaries, not measured customer traffic.

Calculate the boundaries before the duration

For a local calendar day, construct midnight on the chosen date and midnight on the following date in the same named time zone. Convert both to UTC, then subtract them to measure elapsed time. Do not replace the second boundary with the first plus 86,400 seconds.

This Python example uses zoneinfo and the IANA time zone data available on the machine. It needs Python 3.9 or newer and installed time zone data. If that data is unavailable, install the first-party tzdata package rather than substituting a fixed UTC offset. The Python documentation describes that dependency.

from datetime import date, datetime, time, timedelta, timezone
from zoneinfo import ZoneInfo

zone = ZoneInfo("Europe/Zurich")
utc = timezone.utc

for day in (date(2026, 3, 29), date(2026, 10, 24), date(2026, 10, 25)):
    start = datetime.combine(day, time.min, tzinfo=zone)
    end = datetime.combine(day + timedelta(days=1), time.min, tzinfo=zone)
    start_utc = start.astimezone(utc)
    end_utc = end.astimezone(utc)
    hours = (end_utc - start_utc).total_seconds() / 3600
    print(f"{day}: {hours:g}h | {start_utc.isoformat()} to {end_utc.isoformat()}")

for fold in (0, 1):
    local = datetime(2026, 10, 25, 2, 30, tzinfo=zone, fold=fold)
    print(f"02:30 fold={fold}: {local.astimezone(utc).isoformat()}")

The output is:

2026-03-29: 23h | 2026-03-28T23:00:00+00:00 to 2026-03-29T22:00:00+00:00
2026-10-24: 24h | 2026-10-23T22:00:00+00:00 to 2026-10-24T22:00:00+00:00
2026-10-25: 25h | 2026-10-24T22:00:00+00:00 to 2026-10-25T23:00:00+00:00
02:30 fold=0: 2026-10-25T00:30:00+00:00
02:30 fold=1: 2026-10-25T01:30:00+00:00

The subtraction is deliberately done after conversion to UTC. Python’s datetime subtraction rules use wall-time arithmetic when two aware datetimes share the same tzinfo object. That is not the elapsed-time calculation shown here.

The two fold values identify different occurrences of 02:30 during the repeated hour. A label containing only the local clock time cannot distinguish them. Preserve the event’s actual instant and show an offset or another unambiguous identifier where repeated local labels matter.

This is a local calculation. It makes no analytics requests, changes no account settings, and does not demonstrate a timezone switch in a product.

Keep a calendar day separate from a rolling 24 hours

“Yesterday in Zurich” and “the last 24 hours” answer different questions. The first follows calendar boundaries in a named region. The second is an elapsed-duration window ending at an instant.

A current-day report is another case: it may be partial. Comparing today at 10:00 with all of yesterday adds an exposure difference even when there is no clock change.

Keep the time zone, start, end and grouping convention with an export or comparison. A display label is not enough. If a chart shows local hours, inspect how it represents the repeated hour instead of assuming that 24 visible labels mean 24 elapsed hours.

For a business-day analysis in another region, calculate that region’s boundaries. Do not carry Zurich’s offsets into another market or hard-code a one-hour change as a universal rule.

More time can produce more events without a higher rate

Suppose a hypothetical system records exactly 10 events per elapsed hour. A 24-hour window contains 240 events; a 25-hour window contains 250. The total is about 4.17 percent higher, while the hourly rate is unchanged.

That is arithmetic, not a forecast of real traffic. People do not visit at a constant rate, and weekday, campaign and audience mix still matter. Dividing by hours can help investigate event intensity; it does not automatically make two days comparable.

Nor should every metric be normalized by hours. Unique visitors are not an additive event counter. A conversion rate needs a clearly defined eligible population and observation window, not just an extra division by the day’s length. The denominator can change the story even when the displayed percentage looks straightforward.

Report both the total and the exposure when the distinction affects the decision. Keep hypothetical examples visibly separate from measured results.

Make the boundary part of the comparison

For a new query, a half-open interval is a useful convention: include events at the start and exclude events at the next boundary. In other words, timestamp >= start AND timestamp < end. Adjacent intervals then share a boundary without counting an event at that boundary twice.

Do not silently change an existing report’s contract to match this convention. When reconciling exports, check its actual end-time inclusivity, timestamp precision, filters, processing status and counting unit. The same date text does not establish that those rules agree.

A practical test set includes an ordinary local day, the spring transition, the autumn transition, an event exactly on each boundary, and both occurrences of a repeated local time. Keep the expected UTC instants beside the test.

The aim is not to force every dashboard onto one time zone. UTC can be the right operational basis; a local calendar day can be the right business basis. Name the one you use, and compare matching windows before interpreting the difference as growth.

A redirect can erase your campaign tags

Zenovay — Mon, 26 Oct 2026 17:00:00 +0000

You tag a newsletter link, click it, and arrive on the right page. The page looks fine. Later, the campaign report has less traffic than you expected.

Before changing the attribution model, check what happened to the URL. A redirect can deliver the visitor to the correct page while leaving the campaign parameters behind. The click happened, but the destination page may never have received the labels attached to it.

Test the published link, not just the destination

Start with the exact link a reader receives, including any shortener or email wrapper. Copying the final page URL into a new tab skips the handoffs you need to inspect.

For example, a campaign link might contain utm_source=newsletter, utm_medium=email, and utm_campaign=autumn. Those values label the visit. They do not prove that the reader is a new person, that a purchase happened, or that the campaign caused one.

Keep a small record of the journey:

Checkpoint	What to inspect	What it establishes
Published link	The actual address and campaign values	What the sender intended to pass
Each redirect	The response and its Location target	What the next request will receive
Destination page	The URL when the tracker runs	Which labels are available there
Analytics request	The permitted request’s campaign fields	What the browser attempted to send
Report	The campaign, time range, filters, and processing delay	What is visible under that report’s rules

A click, a loaded page, an attempted analytics request, and a reported visit are different checkpoints. Checking only the last one makes a missing label much harder to locate.

A redirect target does not automatically inherit the query

Consider a request to /start?utm_source=newsletter. If the response redirects to /offer, the target names a new path without those query parameters. Do not assume the original query will be attached for you. Relative-reference resolution treats the path and query separately, as described in RFC 3986, section 5.2.

This is not a reason to replace every redirect with a different status code. For this GET example, the important difference is the target address. A change from one redirect status to another does not, by itself, add missing campaign values to that address.

A hostname change, a language route, or a link wrapper is a place to inspect, not proof of a problem. Some handoffs preserve the query correctly. Others intentionally remove particular parameters. Read the actual response rather than diagnosing from the route’s name.

Run a small example before changing a live campaign

The following Python example starts a server on your own machine. Both links reach the same offer page. One redirect drops the query; the other forwards only the five standard campaign parameters listed in the code. It makes no request to Zenovay, an email provider, or a customer website.

from http.server import BaseHTTPRequestHandler, HTTPServer
from threading import Thread
from urllib.parse import parse_qsl, urlencode, urlsplit
from urllib.request import urlopen

ALLOWED = {"utm_source", "utm_medium", "utm_campaign", "utm_term", "utm_content"}


class Demo(BaseHTTPRequestHandler):
    def do_GET(self):
        parts = urlsplit(self.path)
        if parts.path in ("/drop", "/keep"):
            fields = parse_qsl(parts.query, keep_blank_values=True)
            query = urlencode([(k, v) for k, v in fields if k in ALLOWED])
            target = "/offer"
            if parts.path == "/keep" and query:
                target += "?" + query
            self.send_response(302)
            self.send_header("Location", target)
            self.send_header("Content-Length", "0")
            self.end_headers()
        else:
            self.send_response(200)
            self.send_header("Content-Length", "5")
            self.end_headers()
            self.wfile.write(b"Offer")

    def log_message(self, *_args):
        pass


with HTTPServer(("127.0.0.1", 0), Demo) as server:
    worker = Thread(target=server.serve_forever, daemon=True)
    worker.start()
    campaign = "utm_source=newsletter&utm_medium=email&utm_campaign=autumn"
    try:
        for route in ("drop", "keep"):
            url = f"http://127.0.0.1:{server.server_port}/{route}?{campaign}"
            with urlopen(url, timeout=2) as response:
                query = urlsplit(response.geturl()).query
                print(f"{route}: {query or '(empty)'}")
    finally:
        server.shutdown()
        worker.join(timeout=2)

The output is:

drop: (empty)
keep: utm_source=newsletter&utm_medium=email&utm_campaign=autumn

Both pages are reachable. Only one final URL contains the campaign labels. This is a URL-retention demonstration, not a simulation of an analytics report or an attribution model.

The allowlist is deliberate. Do not solve campaign loss by forwarding every incoming parameter to every destination. Links can contain tokens, personal information, or values that belong only to the original endpoint. Decide which fields should cross each boundary and encode them correctly. The example keeps a fixed local destination; it is not a general redirect service.

Check when the tracker sees the URL

A server redirect happens before the destination page’s script can run. Capturing parameters early on that page cannot recover labels that never reached it.

There is a separate timing question after the page loads. A router or another script might clean the address before analytics reads it. Test the order in your own setup instead of treating a clean address bar as proof that nothing was captured.

Zenovay’s browser tracker captures the five standard UTM fields from the page URL when the script loads. That gives it an early view of the address it receives. It is not a promise to reconstruct an earlier redirect URL or identify every campaign when the input is missing.

Use your browser’s Network panel to preserve the navigation log. Follow the redirect chain, inspect the destination URL, and then inspect the analytics request if your test setup permits one. Seeing fields in a request proves an attempt to send them, not successful ingestion or appearance in a report. Check those later stages separately.

Test the link as published on both a fresh visit and a normal returning visit. Existing session state can otherwise make a broken handoff look healthy. Do not weaken privacy settings or add personal information to URLs to make attribution look more complete.

Retest the whole path, then interpret the report

After a change, repeat the original link journey. Confirm the approved campaign fields survive every intended handoff and reach the relevant analytics request. Record the test time and allow for the report’s normal processing and filtering rules.

Use the same campaign spelling and a time range that includes the test. Do not use a report total as a substitute for inspecting one known request. Conversely, do not treat one successful test as proof that every email client, device, or route behaves the same way.

If labels still disappear, keep the uncertainty specific: missing from the destination URL, present in the browser request but not yet verified downstream, or visible under a different report filter. Those findings lead to different next steps.

Once the input survives the journey, there is still a modelling question. The same sale can receive different credit under different attribution models. Preserving campaign tags improves the evidence available to that model. It does not turn a campaign label into proof of causation.

The useful test is simple: follow the link someone will actually click, and check what survives each handoff. A page that loads correctly is only part of a working campaign link.

A green uptime check does not mean checkout works

Zenovay — Mon, 19 Oct 2026 16:00:00 +0000

A homepage returns 200. The uptime monitor receives the response it expects. A shopper opens checkout and cannot finish the order. All three observations can be true at the same time.

A useful monitor has a clear contract: what it requests, what it checks, and which conclusion its result supports. The trouble starts when “the page responded” quietly becomes “customers can buy.”

Say what the green check actually proves

HTTP success is specific to a request. For a GET request, a 200 response describes the successful retrieval of a representation of the resource. It does not report the result of a later action that the request never performed. That distinction follows from the HTTP semantics in RFC 9110.

A homepage request does not submit a checkout form. It does not establish that a browser loaded a payment widget, that a customer could authenticate, or that an order reached the system of record.

Different checks provide different evidence:

Signal	What it can establish	What still needs checking
HTTP availability	The requested URL returned the configured status within the check’s limits	Whether the user journey works
Response content	The returned body contains an expected marker	Whether scripts and interactions succeed
Browser journey	The tested flow reaches a defined result in that environment	Whether real production outcomes agree
Production outcome	A real outcome was recorded by its authoritative system	Whether other users can complete the flow

In Zenovay, uptime configuration supports an expected HTTP status and an optional keyword check on the returned response body. A keyword adds a content assertion to the request check. It does not execute the page’s JavaScript or complete a browser journey.

A status and a keyword can both pass while checkout is unavailable

A broad keyword can be present in an error page. “Checkout” might appear in a heading, navigation, or an unavailable message. Finding that word does not establish that checkout is ready.

Here is a deliberately simplified local example. It makes one request to a temporary server on your own machine and calls no real checkout or payment service:

from http.server import BaseHTTPRequestHandler, HTTPServer
from threading import Thread
from urllib.request import urlopen

PAGE = b"<h1>Checkout</h1><p>Payment service unavailable</p>"


class Demo(BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.send_header("Content-Type", "text/html; charset=utf-8")
        self.send_header("Content-Length", str(len(PAGE)))
        self.end_headers()
        self.wfile.write(PAGE)

    def log_message(self, *_args):
        pass


with HTTPServer(("127.0.0.1", 0), Demo) as server:
    server.timeout = 2
    worker = Thread(target=server.handle_request, daemon=True)
    worker.start()
    url = f"http://127.0.0.1:{server.server_port}/checkout"
    with urlopen(url, timeout=2) as response:
        body = response.read()
        print("status:", response.status)
        print("keyword_found:", b"Checkout" in body)
        print("blocked_message:", b"Payment service unavailable" in body)
    worker.join(timeout=2)

The result is:

status: 200
keyword_found: True
blocked_message: True

The status check passes. A keyword check for “Checkout” passes. The returned page still says the payment service is unavailable. This demonstrates the scope of those assertions, not a recommended way to encode an application failure.

Choose a stable marker that appears only in the intended state. Avoid text shared by the normal page and its fallback. Keep the response status and body consistent with the endpoint’s contract. Even a good content assertion remains evidence about that response.

Test the browser path to a meaningful result

For an important journey, write down the smallest useful sequence: open the page, select the intended option, submit the form, and verify the result that matters.

An enabled button or a click event is usually too early. A success banner can also be too early if the operation finishes asynchronously. Where appropriate, confirm the resulting order, installation, or other state in the system that owns it.

Use isolated test accounts and a sandbox for synthetic purchase checks. Design repeatable inputs and cleanup so the test does not create real charges, pollute customer metrics, or consume limited inventory. A sandbox result describes that environment; it does not certify the entire production payment path.

Separate browser testing complements a request monitor. It is a different check with its own environment, assertions, and maintenance needs. It should not be implied by the uptime badge.

Keep production outcomes alongside synthetic checks

A synthetic check follows the path you chose. Real users bring other devices, accounts, networks, and inputs. Look at production outcomes as another source of evidence, with their own coverage limits.

For checkout, an event named “purchase” should have a precise meaning. A click on Pay and a confirmed payment are different milestones. Reconcile the result with the authoritative order or payment state rather than assuming the browser event proves completion.

A sudden drop in completed orders is worth investigating, but it is not an outage diagnosis on its own. Check eligible traffic, the observation period, tracking coverage, and whether people had enough time to finish. The same care applies to a conversion rate that changes with the audience mix.

Availability, browser behavior, and completed outcomes can disagree without any one of the measurements being fabricated. The useful response is to investigate the gap between their scopes.

Write an alert someone can act on

An alert should identify the failed assertion. “Homepage returned an unexpected status” and “sandbox checkout did not reach confirmation” send the responder to different places.

Include the checked URL or flow, the environment, the failed step, the observation time, and enough request or browser evidence to reproduce the result. Keep credentials and customer data out of alerts and screenshots.

Choose the check frequency and retry policy around the failure you need to catch. A scheduled check observes specific moments; a green result between checks does not describe every request in the interval. Repeated failures can reduce noise, while also delaying detection. Make that tradeoff explicit.

Before calling the service recovered, repeat the assertion that failed. A returning homepage response does not verify that a checkout failure has cleared. Recovery means the relevant check passes again, with production outcomes used to confirm the wider picture.

A green indicator is useful when everyone knows what earned it. Name that evidence precisely, and the monitor becomes easier to trust and easier to act on.

When conversion rates rise overall but fall in every segment

Zenovay — Fri, 09 Oct 2026 19:59:33 +0000

Both acquisition groups convert less often. The overall conversion rate more than triples. There is no missing event and no arithmetic error.

Here is a hypothetical funnel with two mutually exclusive groups, Email and Search. Use the same rule to assign each recorded entry to one group in both periods. These are illustrative counts, not Zenovay customer results or channel benchmarks.

Period	Group	Recorded entries	Completions	Rate
A	Email	100	20	20%
A	Search	1,900	38	2%
A	Total	2,000	58	2.9%
B	Email	1,000	180	18%
B	Search	1,000	15	1.5%
B	Total	2,000	195	9.75%

Email falls from 20 to 18 percent. Search falls from 2 to 1.5 percent. Yet the overall rate rises from 2.9 to 9.75 percent, with the same total number of entries.

The difference is the audience mix: Email goes from 5 percent of entries to 50 percent. Its rate is lower than before, but it still converts more often than Search. Moving more of the traffic into that group changes the aggregate.

The overall rate is answering a different question

This is an example of Simpson’s paradox: the direction of an aggregate comparison can reverse within every subgroup. It is a known statistical effect, not a new discovery or a defect in the calculation.

The overall rate asks what share of this period’s recorded entries completed the funnel. The group rates ask what happened within Email and within Search. Those populations changed their relative size, so the aggregate is not holding the audience mix constant.

The second period does produce more completions: 195 instead of 58. That may be a valuable business result. But it does not show that the flow became easier for either group. The observed rate fell in both.

Before crediting a redesign, ask which result the claim is about: more total outcomes, a different audience, or better conversion within a comparable audience.

Hold the audience mix fixed

One useful descriptive check is to choose a reference mix and apply it to both periods’ group rates. Here, use period A’s mix: 5 percent Email and 95 percent Search.

For period B, the calculation is 0.05 × 18% + 0.95 × 1.5% = 2.325%.

Period	Observed overall rate	Rate with period A’s mix
A	2.9%	2.9%
B	9.75%	2.325%

With the mix held fixed, the rate falls. This separates the changing group weights from the changing rates within those groups.

Choose and document the reference population before judging the result. Use the same mutually exclusive groups in both periods. If a group has no observed entries in one period, its rate is undefined; do not silently turn that missing rate into zero.

Here is the calculation as a self-contained PostgreSQL query. It uses only the four hypothetical rows above:

WITH sample(period, segment, entries, completions) AS (
  VALUES ('A', 'Email', 100, 20),
         ('A', 'Search', 1900, 38),
         ('B', 'Email', 1000, 180),
         ('B', 'Search', 1000, 15)
), rates AS (
  SELECT *, completions::numeric / entries AS rate
  FROM sample
), baseline AS (
  SELECT segment,
         entries::numeric / SUM(entries) OVER () AS weight
  FROM sample WHERE period = 'A'
)
SELECT r.period,
       ROUND(100.0 * SUM(r.completions) / SUM(r.entries), 3)
         AS observed_pct,
       ROUND(100.0 * SUM(r.rate * b.weight), 3)
         AS fixed_mix_pct
FROM rates r JOIN baseline b USING (segment)
GROUP BY r.period ORDER BY r.period;

Reweighting answers a comparison question. It does not establish what a redesign caused, or predict exactly how a future audience will behave.

Step rates have their own denominator

The same care applies within a funnel. Suppose 1,000 recorded entries produce 400 signups and 100 final completions. Overall completion is 10 percent. Signup to completion is 25 percent. Both calculations are correct because their denominators differ.

In Zenovay, the overall funnel rate compares recorded completions with recorded entries. For transitions after the first step, the step breakdown uses the preceding step for its conversion calculation. Read each rate with its counts and its scope.

People, sessions, funnel entries, and event occurrences are different counting units. Someone can return several times or repeat an action. A recorded entry is not a verified individual. Keep the unit explicit when comparing reports.

Keep the definitions and observation window fixed

A smaller denominator can also raise a rate without adding a single completion: 100 out of 1,000 is 10 percent; 100 out of 500 is 20 percent. Moving the entry point closer to checkout changes the measurement, even if the report keeps the same name.

Use the same entry rule, final event, counting unit, and group definitions. Record changes to URL rules or funnel steps and establish a new baseline when the meaning of the measure changes.

Time matters too. Yesterday’s entrants have had less opportunity to finish a long journey than entrants from two weeks ago. For a cohort comparison, choose an entry period and a fixed follow-up window, then let both groups reach it. A calendar report of events and a cohort report following entrants are different views.

That is a method for comparing cohorts, not a claim that every funnel report provides that control.

What this calculation can and cannot tell you

The table demonstrates an aggregation reversal. It does not demonstrate why either group’s rate changed. Observed rates can also move through sampling variation, especially when the counts are small.

Predefine the segments that matter to the decision. Show entries and completions alongside percentages. For a claim that a product change caused improvement, use a suitable experiment or another defensible causal design; a segmented before-and-after report alone does not supply that evidence.

A conclusion someone else can check would be: “Completions rose from 58 to 195 across 2,000 recorded entries in each period. Both group rates fell, while Email’s share of entries rose from 5 to 50 percent. Holding period A’s mix fixed gives 2.325 percent for period B, compared with 2.9 percent before.”

That is more useful than “conversion improved.” It tells the team what changed, which comparison improved, and which question still needs an answer.

The 19-year visit that wasn't real

Zenovay — Wed, 30 Sep 2026 17:42:38 +0000

One record in our analytics said a visitor had spent 619,637,320 seconds on a page. That is about 19.6 years. The number came from an automated scanner, not a remarkably patient reader.

That scanner-generated duration was not evidence of a visit, but it could distort an average-time view. It shows why a number can be valid input without being a useful measurement.

A browser timer is a defined measurement, not a direct reading of human attention.

The outlier was data, but it was not evidence of attention

A tracker has to accept information from a visitor's browser. That browser is outside the analytics server's control. A normal page script can report a duration, but a test client can send a number that no real visit could have produced.

The scanner request reported the 19.6-year value in the time_on_page field. Before a browser-reported duration can inform an average, it needs a plausibility boundary and an outlier policy. Otherwise, the average describes the data received, not how long people spent reading.

The size of the number made this case obvious. Smaller errors are harder to notice. A five-hour "visit" might look plausible in a report even when it came from an abandoned tab, a stale clock, or a malformed client. That is why the boundary matters even if nobody ever sees another value measured in years.

An open tab is not an active session

Elapsed time is simple to calculate: subtract the start timestamp from the current timestamp. It is not the same as time spent looking at a page. Someone can open a tab, switch to another app, have lunch, and return. A wall-clock timer would happily count all of it.

Zenovay's current browser tracker treats that gap differently. Its heartbeat checks whether the document is visible and the window has focus. It does not accrue time while the page is hidden or unfocused. While visible, it also stops adding time after five minutes without input. When a hidden tab becomes visible again, it resets the timing reference so the time away is not added in one jump.

These are implementation choices, not a claim that we can measure attention perfectly. A person might read a long article without touching the mouse. Another might interact with a page without absorbing anything. The tracker can distinguish some browser states; it cannot see intent or comprehension.

There is also a naming trap. In Zenovay today, time_on_page can represent accumulated active session time, not a clean per-page stopwatch. The label alone should not be treated as the definition of the metric.

Put a bound where browser data enters

Zenovay now bounds client-reported durations when they arrive. Values above four hours are capped, with an over-limit signal retained separately for investigation. This prevents a multi-year duration from being stored as such, but the cap alone does not make every average meaningful.

An otherwise valid pageview is not rejected solely because its reported duration is implausible. The timing value still needs careful interpretation: a cap is a guardrail, not evidence of genuine attention.

Four hours is a defensive ceiling, not our definition of a normal visit. Even a bounded outlier can skew an average, and a new boundary does not revise past reports. Any duration summary still needs an explicit definition and an outlier check.

Ask what the metric is for

Average time can be a useful clue. If a page's value changes sharply, it is worth checking the underlying events, outliers, traffic sources, and the exact definition of the timer. But a higher average is not automatically better. It can mean sustained reading, a confusing workflow, or simply a measurement problem.

For a product page, the better question may be whether visitors reached the next step. For documentation, it may be whether they found an answer. For an analytics setup flow, it may be whether a real event arrived from the intended website. Duration can add context to those outcomes; it cannot replace them.

The practical lesson is to define what the browser records, bound what a client can report, and inspect unusual values before treating an average as a story about people.

A signup is not activation

Zenovay — Fri, 18 Sep 2026 18:29:48 +0000

A new account is an encouraging notification. It is also a very small piece of evidence.

For an analytics product, someone can create an account, add a website, copy a script, and still never see a visit from their own site. Counting the first step as success hides all the work between signing up and getting something useful.

Our July activation audit started with that gap. The working notes suggested that roughly half of the nominal free accounts had not created a website. But those notes also marked parts of the baseline as inferred and mixed internal, test, and external accounts. That is enough to start investigating. It is not enough to publish a precise conversion rate.

This teardown is about what we can establish: the stages we need to separate, the installation checks the current code performs, and the evidence needed before calling an onboarding change an improvement.

Three steps that should never share one label

Account creation tells us that someone completed registration. Website creation tells us that they configured an object in the product. A first recorded event tells us that data reached that website’s analytics pipeline.

Those are different milestones. None, on its own, proves that the person understood the report or will return next week.

For this audit, the first useful technical checkpoint is a real event recorded for the intended website. That is narrower than product activation, but much easier to verify than a vague label such as “setup complete.”

Someone with no website needs help with the setup decision. Someone with a website and no events needs an installation diagnosis. Someone with events who never returns may have a different problem: the report did not answer a question worth coming back for.

Sending all three people the same reminder assumes the diagnosis before making it.

Read the implementation, not just the score

Zenovay’s current activation scoring function evaluates four milestones: a script installation flag, a first event within 24 hours of website creation, a Stripe connection within seven days of team creation, and a return login after the first day and within fourteen days of team creation. Each achieved milestone contributes 25 points.

The function counts achieved milestones independently. It does not require someone to complete a strict sequence before later milestones can count. That detail matters when interpreting a score: two accounts can reach the same total through different behavior.

A first event arriving after 24 hours also fails the time-bounded milestone even though tracking now works. “Missed the activation window” and “installation is broken” need different responses.

We previously wrote about an installation flag that did not reflect the underlying activity. The broader lesson still applies: a score summarizes its inputs. It cannot tell you whether those inputs are trustworthy.

An empty chart has several possible causes

The current tracking route checks the request origin against the website’s allowed domains. If no explicit list exists, it falls back to the registered domain. A mismatched origin can be rejected in production when domain verification is enabled.

There is also an explicit localhost exception controlled by the website’s allow_localhost setting. That exception belongs to the domain check. It is not a promise that every local test will produce a stored event: other checks still apply.

This is why “I pasted the script” is the beginning of verification, not the end. Check the actual page hostname, the configured website, the browser’s network response, and whether an event was recorded. Use a real browser visit for the user journey you are testing.

Do not weaken a security check simply to make a setup indicator turn green. First find the rejected request and understand why it was rejected. The useful repair may be the configuration, the installation instructions, or the error message.

Count people and websites separately

Subtracting the number of websites from the number of signups does not give the number of people who abandoned onboarding.

One person can create several websites. A colleague can join an existing team without creating any. Test accounts can distort a small sample.

A useful cohort report starts with a defined set of eligible accounts or teams and follows that same set through the stages. Choose the unit, exclusions, and observation window before computing the percentage.

For example, a report of new team owners could ask whether each owner created at least one website and whether any of those websites received a qualifying first event within a fixed window. Count each owner once. Report the underlying counts as well as the percentage. Keep invitations and internal testing separate.

That is a proposed measurement contract, not a claim that the historical July estimate already followed it.

What would count as an improvement?

Before comparing two onboarding versions, give both cohorts the same amount of time to reach the checkpoint. A cohort from yesterday cannot fairly be compared with one that has had two weeks to finish setup.

Track the missing step, not just the final total. Did more eligible owners create a website? Did more of those websites receive an event? Did people return after they had data? Record which changes shipped between cohorts, and keep acquisition sources in view.

We are not claiming a measured uplift from this teardown. A source review can show how a check works and identify a plausible obstacle. It cannot establish why every person left, or prove that removing a step caused more people to stay.

The next time a signup notification arrives, the useful follow-up is simple: did that person get data from their own website, and did it help them do anything?

Until we can answer that, the account count is only the start of the story.

The Same $100 Sale Looks Different Under Every Attribution Model

Zenovay — Mon, 14 Sep 2026 16:00:00 +0000

A customer discovers you through organic search. Two weeks later, they click a social post. Then they return through a paid search ad, open an email, and finally type your address into the browser before buying.

One journey. One $100 sale. Five channels touched it.

Now ask a simple question: which channel generated the revenue?

There is no neutral answer hiding in the data. There is only a rule for assigning credit. Change the rule, and the same sale tells a different story.

That is the part attribution reports often make too easy to forget.

One journey, five touchpoints

For a concrete example, use this path:

Organic Search, 28 days before the purchase
Organic Social, 14 days before the purchase
Paid Search, 7 days before the purchase
Email, 2 days before the purchase
Direct, at the moment of conversion

The order and timing stay fixed. The purchase value stays $100. Only the attribution model changes.

Zenovay currently supports five models in the revenue view: last touch, first touch, linear, position based, and time decay. We ran this example through the same allocation function used by the product.

Here is what each model reports.

Model	Organic Search	Organic Social	Paid Search	Email	Direct
Last touch	$0	$0	$0	$0	$100
First touch	$100	$0	$0	$0	$0
Linear	$20	$20	$20	$20	$20
Position based	$40	$6.67	$6.67	$6.66	$40
Time decay	$2.37	$9.50	$18.99	$31.16	$37.98

None of these rows changes the sale. Each row answers a different question about it.

Last touch asks who closed

Last touch gives all credit to the final known channel. In this journey, Direct receives the full $100.

That can be useful when the question is operational: what brought the customer back at the moment they bought? It is also simple to explain and works when only the current visit is available.

But it can make discovery disappear. Organic Search introduced the product. Social, paid search, and email kept the journey moving. The report still gives them zero.

There is another wrinkle with Direct. A direct visit is often real, but it does not necessarily mean the customer arrived without prior influence. They may have remembered the brand after seeing the earlier touches. Last touch cannot express that history when it assigns everything to the final visit.

First touch asks who introduced

First touch reverses the story. Organic Search receives the full $100 because it was the first known channel in the journey.

This view is useful for discovery. It helps answer which channels bring new people into the measurable path. It can be particularly helpful when evaluating content, communities, or campaigns whose main job is creating awareness.

Its blind spot is the close. An early visit may have introduced the customer, but a later email or paid campaign may have done the work that converted interest into action. First touch cannot share that credit.

Linear refuses to choose

Linear attribution divides the sale evenly across the five distinct channels. Each receives $20.

This is the calmest model in the set. It acknowledges every measured touch and avoids claiming that one position is always more important than another.

That fairness is also its assumption. A quick social click receives the same credit as the email opened two days before purchase. Equal credit is not the absence of a judgment. It is a judgment that all measured touches deserve the same weight.

Position based rewards the beginning and the end

Zenovay's position based model gives 40 percent to the first channel and 40 percent to the last. The remaining 20 percent is split across the channels in the middle.

In our example, Organic Search and Direct receive $40 each. Organic Social, Paid Search, and Email share the remaining $20.

This model fits a common marketing intuition: discovery and conversion matter most, while the middle assists. It preserves both ends of the journey without ignoring everything between them.

But 40, 20, and 40 are still chosen weights. They are not facts observed in the visitor's mind.

Time decay rewards recency

Time decay gives more credit to touches closer to the conversion. Zenovay uses a seven day half life. A touch seven days before the sale receives half the raw weight of a touch at conversion. A touch 14 days before receives one quarter. A touch 28 days before receives one sixteenth.

After normalizing those weights across this journey, Direct receives $37.98, Email $31.16, Paid Search $18.99, Organic Social $9.50, and Organic Search $2.37.

This is useful when recent touches are more likely to influence a decision. It also avoids the hard cliff of last touch, where every earlier interaction instantly becomes worth zero.

The model still embeds a belief: recent interactions deserve more credit, and seven days is the right pace of decay. That may fit one buying cycle and misrepresent another.

The model should follow the question

Teams often ask which model is correct. A better question is what decision the report needs to support.

Use first touch when you are studying discovery. Use last touch when you are studying the final return or close. Use linear when you want a neutral view of all measured participants. Use position based when the first and last touches are strategically important. Use time decay when recency should matter.

The dangerous move is changing models until a preferred channel looks good. If a paid campaign disappoints under last touch, switching to linear may make its revenue rise without changing a single purchase. The new number can be valid under the new rule and still be a poor basis for comparison with the old one.

Pick the question first. Keep the model visible. Do not compare periods that use different rules as if the measurement were unchanged.

History limits matter before model choice

A multi touch model can only allocate credit across touches the system can connect.

In Zenovay, first party cookie tracking can preserve a journey across days. Cookieless mode has less history, so its multi touch result may be limited to the visits that can be linked within the available window. The revenue view marks this as limited history when appropriate.

That does not make the calculation wrong. It makes the boundary of the evidence important. A precise allocation over an incomplete path is still incomplete.

Last touch is less sensitive to missing earlier history because it needs only the final known touch. First touch changes meaning when earlier visits are unavailable. Linear, position based, and time decay can redistribute credit only among the touches they can see.

What we compare in practice

We do not use one model as a machine for discovering truth. We compare models to find where a conclusion is fragile.

If Organic Search performs well under first touch but nearly disappears under time decay, it is probably strong at discovery and distant from conversion. If Email rises sharply under time decay, it may be helping late in the journey. If a channel remains meaningful across all five models, confidence in its role is stronger.

This comparison is more useful than arguing about one universal winner. The disagreement between models is information.

Before acting on an attribution report, we now ask four things:

Which business question are we asking?
Which allocation rule matches that question?
How much visitor history was actually available?
Would the decision change under another reasonable model?

If the answer to the fourth question is yes, the conclusion needs more caution, not more decimal places.

Attribution is a lens, not a receipt

The $100 sale happened once. The five reports are not five competing transaction records. They are five lenses placed over the same journey.

Good attribution makes the lens explicit. It preserves the underlying conversion, documents the rule, and lets the reader see how much the answer depends on that rule.

The goal is not to find a model that ends the discussion. It is to choose a model that makes the discussion honest.

5 Reasons to Switch From Google Analytics in 2026

Zenovay — Thu, 03 Sep 2026 20:21:03 +0000

Google Analytics has been the default for over a decade. It is free, it is everywhere, and most teams set it up without questioning whether they should.

But the product you are using today is not the product you installed five years ago. GA4 arrived in 2023, and with it came a completely different data model, a new interface, and a learning curve that turned experienced analysts into beginners. Two years later, plenty of teams are still struggling with it.

This is not a hit piece. Google Analytics does things no competitor matches at zero cost. But “free” has conditions, and those conditions are getting harder to accept. Here are five reasons teams are switching, and one honest reason you might not want to.

1. The complexity tax is real

GA4 replaced a page-view model with an event-based model. In theory, that is more flexible. In practice, it means the simple questions got harder.

“How many people visited my pricing page last week?” In Universal Analytics, that was one click. In GA4, you might need a custom exploration, a filtered report, or a segment that you build from scratch each time.

The interface has improved since launch, but it is still dense. Navigation is non-obvious. Reports that should be standard require configuration. If you are a founder or a small marketing team, the time you spend learning GA4’s interface is time you are not spending on your product.

Most teams do not need 400 features. They need five metrics they can trust, presented clearly, refreshed in real time.

2. Privacy is not optional anymore

Google Analytics uses cookies. That means you need a consent banner in the EU, the UK, and increasingly in other jurisdictions. Every visitor who declines cookies is a visitor you cannot track.

Estimates vary, but consent rates in Europe typically range from 30% to 70%. That means your GA4 data may represent only half of your actual traffic. The data is not wrong, but it is incomplete, and incomplete data leads to incomplete decisions.

Cookieless analytics tools avoid this problem entirely. No cookies means no consent banner is needed for analytics. Every visitor is counted, every page view is recorded, and your traffic numbers reflect reality instead of the subset that clicked “Accept.”

This is not just a European concern. California’s CCPA, Brazil’s LGPD, and Canada’s PIPEDA all impose obligations on cookie-based tracking. The regulatory direction is clear: tracking will get harder, not easier.

3. Data sampling hides the truth

GA4 samples data when your query exceeds certain thresholds. You will see a small icon in the corner of your report, easy to miss, telling you that you are looking at an estimate based on a fraction of your actual data.

For large sites, this happens constantly. For smaller sites, it happens less often, but when it does, you may not notice. The numbers look plausible. They are just not exact.

Sampling is a reasonable engineering trade-off for a free product serving millions of sites. But if your business decisions depend on accurate numbers, and they should, you need to know whether you are looking at real data or an approximation.

Most modern analytics alternatives process every event without sampling. What you see is what happened.

4. Your data trains the advertising machine

Google is an advertising company. Google Analytics is a product that helps that advertising company understand the web. The data you send to GA4 feeds into Google’s broader ecosystem, informing ad targeting, benchmarks, and audience modeling.

This is not a secret conspiracy. It is the business model. Google does not charge for GA4 because your data has value to them in other ways.

If you are comfortable with that trade, fair enough. Many businesses are, and they get a capable product in return. But you should make that choice consciously, not by default because you set up GA years ago and never revisited the decision.

Self-hosted and cookieless alternatives keep your data entirely under your control. The analytics vendor does not see it, does not aggregate it, and does not use it for anything except showing you your own numbers.

5. The script weight adds up

The Google Analytics gtag.js script weighs roughly 90 KB (compressed). On its own, that is not catastrophic. But it rarely arrives alone. It brings Google Tag Manager, additional tracking pixels, remarketing tags, and consent management scripts along for the ride.

A typical GA4 + GTM setup can add 200 to 400 KB of JavaScript to every page load. That matters for Core Web Vitals. It matters for mobile users on slow connections. It matters for your Lighthouse score, and that score affects how Google ranks you.

There is an irony here: Google’s own analytics tool can hurt your ranking in Google’s own search engine.

Lightweight alternatives typically ship scripts under 5 KB. The difference is measurable in your performance metrics.

One honest reason to stay

If you run Google Ads at scale, GA4’s integration with the Google advertising ecosystem is genuinely hard to replace. Conversion tracking, audience building, and campaign attribution all flow through a shared data layer that competitors cannot replicate.

For teams where paid Google advertising is the primary growth channel, switching away from GA4 means rebuilding that integration from scratch. That is a real cost, and it may not be worth it.

But for teams that grow through organic search, content, referrals, or product-led growth, that integration is irrelevant. You are carrying the complexity and privacy cost of GA4 without using the one thing that justifies it.

What switching actually looks like

Switching analytics tools sounds like a big project. In practice, it is usually one script tag.

Remove the GA4 snippet. Add a new one. Most modern analytics tools, including Zenovay, take under five minutes to install and start showing data immediately. There is no configuration wizard, no goal setup, no event taxonomy to define before you see your first page view.

You do not need to switch all at once. Run both tools in parallel for a month. Compare the numbers. When you are confident the new tool gives you what you need, remove GA4.

The sunk cost of years of GA data feels like a reason to stay. But ask yourself: when was the last time you actually looked at data from two years ago? Most analytics decisions use the last 30 to 90 days. The historical archive rarely matters as much as it feels like it should.

Choosing an alternative

There is no single best alternative. The right choice depends on what you actually need:

If you want the simplest possible dashboard with no configuration, look at privacy-focused tools like Plausible or Fathom.
If you need revenue attribution, funnels, heatmaps, and session replay in one tool, Zenovay covers all of those without cookies.
If you want full control and self-hosting, Matomo or Umami are solid options.
If you are evaluating multiple options, our comparison of GA alternatives breaks down the trade-offs in detail.

The important thing is to make a deliberate choice. Google Analytics became the default because it was free and early. Those are not reasons to keep using something in 2026.

Frequently Asked Questions

Is Google Analytics really free?

GA4 is free to use, but the cost is indirect. Your website data feeds into Google's advertising ecosystem, and the complexity of the tool costs your team time.

Will I lose historical data if I switch?

Your GA4 data stays in your Google account. You can export it before switching. However, most analytics decisions rely on the last 30 to 90 days of data.

Do cookieless analytics tools comply with GDPR?

Cookieless analytics tools are designed for GDPR readiness because they do not store personal data or set cookies. Most do not require a consent banner.

Can I use a GA alternative alongside Google Ads?

Yes. You can use a cookieless analytics tool for your website analytics while keeping a minimal GA4 or Google Tag setup specifically for ad conversion tracking.

How long does it take to switch analytics tools?

Most modern analytics tools can be installed in under five minutes. You add a single script tag to your site.

A Boolean We Never Set to True Told Us Every Customer Was Inactive

Zenovay — Sun, 23 Aug 2026 09:35:52 +0000

I found an analytics bug inside our own analytics product.

The event pipeline worked. Real sites sent real events. An internal boolean still said the tracking script was not installed.

That contradiction mattered because the flag was the first milestone in our activation score. If it stayed false, a working site could remain in the cold segment even after data arrived.

On 21 July, production had 36 sites. Twenty one had received a first event. Only two had script_installed set to true.

Nineteen working installations were described as inactive.

The problem was not a delayed queue or a failed tracker. We had created a state transition that no production path ever performed.

The value was correct at creation

When a customer created a site, script_installed started as false. That was reasonable. At that moment, Zenovay had not received proof that the script was running.

The missing part came later.

Our system recorded the first event timestamp when data arrived, but nothing changed the installation flag. The flag had one writer for the initial false value and no writer for the later true value.

Tests made the mistake easy to miss. They supplied fixtures where script_installed was already true, then verified that the activation score handled the value correctly.

The scoring function was tested. The transition that created its input was not.

Two fields described one fact

We already had a stronger signal: first_event_at.

That timestamp only exists after the ingestion path accepts a real analytics event for the site. It is evidence of something that happened. The boolean was only a description of that evidence.

Once both fields existed, they could disagree:

select count(*)
from websites
where first_event_at is not null
  and script_installed is distinct from true;

The query returned 19.

This is the risk of duplicate state. Each field can look valid in isolation. The contradiction appears only when the relationship between them is checked.

Why the damage stayed internal

The customer facing installation check used a safer condition. It only warned when both the flag was false and no first event existed. Customers with real data were not incorrectly told to reinstall the tracker.

The activation cron was also read only. It recorded telemetry and did not send lifecycle emails.

That limited the blast radius, but it did not make the bug harmless. Internal activation reporting was classifying working teams incorrectly. Any decision based on that segment would start from false evidence.

The repair

We attached the missing transition to the event that proves installation.

When the first visitor event arrives, the same database trigger that records the first event now sets script_installed to true and records when the script was first seen.

The update is guarded. It runs only while verification is pending or the installation flag is not already true. Later page views do not rewrite the same site row or produce a new audit entry for every event.

We then backfilled the 19 inconsistent rows from the existing first event evidence.

After the repair, the historical production state had 21 sites with a first event and 21 with the installation flag set. The mismatch count was zero.

A fresh production check on 20 August still returned zero sites with events but a false installation flag, and zero sites with a true flag but no first event.

What we changed in the review process

The code fix was small. The review change is more useful.

First, activation milestones need an observable event. “The script is installed” is a label. “The first event was accepted at this time” is evidence.

Second, tests need to cover the transition that produces state. A perfect unit test for the scoring function could not reveal that production never supplied the true value.

Third, duplicated facts need an invariant. If two fields are expected to agree, run the contradiction query continuously. Do not wait for a manual audit.

Fourth, internal analytics deserve the same skepticism as customer analytics. A polished funnel can still measure fiction when one milestone is derived from stale state.

The question we use now

We no longer ask only whether the installation flag is true.

We ask which irreversible event proves the milestone happened.

For tracker installation, that event is simple: the first event arrived.

What status in your product is treated as fact even though no production event is responsible for changing it?

Our Ahrefs Domain Rating Fell From 23 to 6

Zenovay — Fri, 14 Aug 2026 17:25:01 +0000

Our Ahrefs Domain Rating fell from 23 to 6. The number was hard to ignore. It was also not an explanation.

That distinction shaped the investigation. A third party score can tell you that something changed in its model. It cannot tell you which technical decision caused the change, or whether the same movement appears in search performance. So we treated the drop as a prompt to inspect the site, not as a verdict.

The inspection found a real problem at the root URL. For visitors without an existing language preference, the same URL could return a temporary redirect to different locale paths depending on the request location. That behavior was inconsistent with the permanent locale structure we wanted search engines to understand.

We fixed it. We still cannot honestly say that this redirect caused the Domain Rating drop.

What the score actually tells us

Ahrefs defines Domain Rating as a relative measure of a website's backlink profile on a 0 to 100 scale. The calculation depends on the sites linking to a domain and on the wider Ahrefs index. A score can therefore move even when a site has not lost the same proportion of backlinks.

Ahrefs also states that Domain Rating is not a Google ranking factor. It is useful for comparing backlink profiles and noticing changes, but it is not a direct measurement of how Google ranks a page.

That left us with two separate facts:

We observed the score fall from 23 to 6.
Our root redirect behavior needed to be corrected.

The facts existed at the same time. Their timing did not prove that one caused the other.

What the root URL was doing

The old middleware selected a locale from the request country when no locale preference was already present. It then redirected a nonlocalized path such as the root URL to that locale with a 302 response.

In simplified form, the relevant behavior looked like this:

const country = request.cf?.country
  || request.headers.get('CF-IPCountry')
  || 'US'

const targetLocale = LOCALE_MAP[country] || 'en'

return new Response(null, {
  status: 302,
  headers: { Location: `/${targetLocale}/` },
})

The code was trying to be helpful. A visitor in Germany could be sent to the German locale, while a visitor in the United States could be sent to English.

The problem was the crawler facing contract. One source URL did not have one stable destination. Its response depended on location, and the redirect said the move was temporary.

This matters because Google treats permanent and temporary redirects differently. Its redirect guidance says that permanent redirects such as 301 and 308 are strong signals that the target should become canonical. With temporary redirects such as 302 and 307, the source generally remains the canonical URL in search results.

Temporary redirects are valid when a change really is temporary. They are the wrong default when the site has a permanent locale hierarchy and needs a deterministic canonical entry point.

Why location dependent routing was risky

Imagine two crawlers requesting the same root URL from different locations. One receives a redirect to /en/. The other receives a redirect to /de/. Both responses are temporary.

Nothing in either response tells a stable story about the site's preferred root destination. The behavior can also make external tools record different chains depending on where and when they crawl.

This does not automatically destroy authority, and a 302 is not a penalty. Search engines can interpret redirects using more than the status code alone. The issue was that our implementation mixed three concerns in one response:

The permanent structure of the site
The visitor's likely language
The visitor's saved preference

Those concerns deserve different handling. The canonical route should be stable. Personalization should happen only when there is an explicit preference or after the stable page has loaded.

The deterministic fix

The corrected middleware separates a new request from a returning visitor with a saved locale choice.

For a cookieless request to a nonlocalized path, the server now returns a permanent 301 redirect to the English path. The destination is the same regardless of country:

https://zenovay.com/  ->  https://zenovay.com/en/

For a visitor who already has a locale preference cookie, the middleware can still honor that personal choice with a temporary redirect. That is a genuinely user specific response, not a claim about the site's canonical structure.

This is a small code change with a useful property: a crawler and a clean browser now see one predictable first hop. We verified the live root response with ordinary requests, Googlebot requests, and different language headers. Each returned a 301 to the same English URL.

The fix does not require us to remove localized pages. Every locale still has its own URL. Language selectors and saved preferences still serve visitors. The change only makes the default entry path deterministic.

What we can conclude, and what we cannot

We can conclude that the old root redirect was a technical flaw. It used a temporary status for a permanent site structure and allowed the destination to vary by request location. The current behavior is easier for crawlers, external auditing tools, and humans to reason about.

We cannot conclude that the flaw caused the entire Ahrefs score change. We do not have a controlled experiment that isolates the redirect from changes in Ahrefs' index, the backlink graph, referring domains, or other site factors.

We also cannot claim a recovery before the data shows one. Shipping the fix is the start of observation, not the end of the story.

The responsible approach is to record the change date and watch several signals separately:

Domain Rating and the referring domains behind it
Newly discovered and lost backlinks
Search impressions and clicks from first party search data
Indexing and canonical selection for the root and locale pages
The redirect response seen from clean requests over time

If those signals improve together after the fix, the evidence becomes more interesting. It still needs cautious interpretation.

A practical redirect audit

You do not need a large SEO platform to catch this class of problem. Start with the HTTP response itself.

Request the root URL without cookies and record the status and Location header.
Repeat the request with different language headers and, if possible, from different regions.
Confirm that permanent public routes have one deterministic destination.
Follow the chain and check that it ends without extra hops or loops.
Inspect the final page's canonical and alternate language links.
Test a returning visitor with an explicit locale preference separately.
Save the result and the deployment date so later metric changes have context.

A useful command line check is deliberately boring:

curl -I https://example.com/

Then vary only one input at a time. Add an Accept-Language header. Use a clean cookie jar. Run the request from another region. If the public URL is supposed to have a single canonical destination, the first hop should not become a geography lottery.

The broader lesson

Metric drops create pressure for a quick story. A quick story is often where a technical observation becomes an unsupported causal claim.

The better sequence is slower and more useful:

Confirm what the metric measures.
Inspect the system for concrete defects.
Fix defects because they are defects.
Separate verified behavior from hypotheses about impact.
Watch primary and third party signals after the change.

Our Domain Rating drop led us to a real redirect problem. Correcting that problem gave the site a stable canonical entry path. Whether it explains the score movement remains an open question, and we would rather leave that question open than manufacture certainty.

That is the kind of debugging record we trust: exact about the code, careful about causation, and clear about what to measure next.

Sources

Traffic increased 18 percent is not an insight

Zenovay — Thu, 06 Aug 2026 20:13:43 +0000

Traffic increased 18 percent. Compared with what? Driven by whom? Did those visitors do anything useful? Is the change large enough to matter, and what should someone inspect next?

Until those questions have answers, 18 percent is a measurement. It is not an insight.

This distinction matters because analytics products are getting better at turning charts into sentences. A sentence feels more complete than a chart label, but grammar does not create judgment. If a tool only restates the visible movement, it has saved you a glance and left the actual analysis untouched.

The 18 percent in this article is an illustrative example. It is not a Zenovay traffic result.

An observation is not a decision

Suppose a dashboard compares the last seven days with the seven days before them and reports:

Traffic increased 18 percent.

That statement answers one narrow question: how did the total change between two windows?

It does not tell you whether the earlier week was unusually quiet, whether one campaign created the increase, whether bot traffic distorted the count, whether the lift came from a useful market, or whether any of the new visitors engaged or converted.

The number can be correct and still be unhelpful.

The minimum useful unit is not a percentage. It is a chain:

Observation: What changed, and by how much?
Context: Compared with which baseline, over which period, and with what normal variation?
Explanation: Which segments changed enough to plausibly account for the movement?
Impact: Did the change affect a business outcome or only a surface metric?
Next check: What should a person inspect or test now?

That chain does not need to be long. It needs to be honest.

Start with a baseline that deserves trust

The previous period is convenient, but it is not always representative. A product launch, holiday, outage, paid campaign, or unusually strong post can make one week a poor baseline for the next.

A better comparison uses recent history and keeps the time windows equivalent. For example, compare Tuesday through Monday with several previous Tuesday through Monday windows. If the business has a strong weekday pattern, comparing a Monday with a Sunday produces noise that looks like news.

In Zenovay's current insight service, expected values are calculated from up to four recent nonempty weekly periods, with more weight given to the most recent weeks. The same service keeps the latest week available as a separate comparison. That design does not make the baseline perfect, but it makes a single unusual week less powerful.

The practical question is simple: would the statement still look interesting if you changed the baseline?

If an 18 percent rise becomes 2 percent against the recent average, the story changes. If it remains 18 percent across several sensible comparisons, it deserves attention.

Decompose the total before you explain it

Aggregate traffic is where analysis starts, not where it ends. The next step is to find where the change lives.

Useful cuts often include:

Referrer or campaign
Landing page
Country or region
Device type
New and returning visitors
Engagement or value segment

Imagine the total grew 18 percent, but almost all of the additional visits came from one referral source and landed on one article. That is a much more useful observation. It narrows the search and gives the team something concrete to inspect.

Now compare that source with the rest of the traffic. Did its visitors interact? Did they reach important pages? Did they complete a goal? A volume increase with weaker visitor quality can be less valuable than a smaller increase from a source that reaches the intended audience.

Zenovay's current insight path assembles total visitors, engagement rate, average value score, the share of high value visitors, and leading countries, devices, referrers, and landing pages before it asks for an interpretation. Those fields reflect what the code actually provides today. They are context for analysis, not proof of causation.

Treat causes as hypotheses

This is where many automated summaries become overconfident.

If traffic rose after a campaign launched, the campaign may have contributed. The timing alone does not prove that it caused the full increase. Organic search, a referral, a returning audience, a tracking change, or simple variation may also be involved.

A responsible insight separates evidence from inference:

Evidence: Visits from the campaign source rose during the period and account for most of the total increase.

Hypothesis: The campaign is the leading explanation for the lift.

Check: Compare tagged campaign visits, landing pages, engagement, and goal completions with the prior baseline.

That wording is slightly less dramatic. It is also far more useful because it tells the reader how to prove or reject the explanation.

Connect traffic to an outcome

More visits are not automatically good. They can be useful, irrelevant, expensive, accidental, or fraudulent. The meaning depends on what the site is meant to achieve.

For a content site, the next signal might be meaningful interaction or a return visit. For a product site, it might be a signup, an activated account, or a qualified lead. For commerce, it might be revenue, order value, or a completed checkout.

This is why the phrase “traffic increased 18 percent” feels unfinished. It describes movement at the top of a system while ignoring what happened next.

A better statement might read:

Traffic was 18 percent above the recent weekly baseline. Most of the lift came from one referral source and one landing page. Those visitors engaged at a lower rate than the site average, so check the source message and landing page fit before increasing spend.

That example contains a baseline, a segment, an outcome, and a next action. It still avoids claiming a cause that the data has not established.

Give every insight a next check

An insight should reduce the distance between noticing and deciding. If the reader still has to ask “so what do I do now?”, the summary stopped too early.

The next step should be specific enough to perform and modest enough to trust. Good examples include:

Compare the leading source with the recent weekly baseline
Open the landing page that received the new traffic
Check engagement and goal completion for that segment
Verify whether a campaign, release, or tracking change happened in the same window
Watch the pattern for another equivalent period before changing budget

Zenovay's current AI insight format includes a metric name, current value, expected value, percentage change, description, severity, and recommendation. Its chart narrative path also combines trend, peak, low, recent data points, and a requested action. If the AI service is unavailable, the product can fall back to rule-based summaries. These implementation details matter because a useful product needs a defined output contract, relevant evidence, and a graceful failure mode. A clever sentence alone is not enough.

A five question test for any AI insight

Before acting on an automated insight, ask:

What exactly changed? The metric, window, and amount should be explicit.
What is the baseline? Previous period, recent average, forecast, or benchmark should not be hidden.
Where did the change happen? Look for the source, page, device, geography, or visitor segment that explains the aggregate.
What evidence supports the explanation? Timing is useful evidence, but it is not causation.
What is the next check? The recommendation should be concrete and reversible when confidence is limited.

If a statement fails these questions, treat it as a notification. Notifications can still be valuable. They tell you where to look. They should not pretend the looking has already been done.

The standard is useful uncertainty

Good analytics does not eliminate uncertainty. It makes uncertainty visible and gives you a better next move.

“Traffic increased 18 percent” sounds certain because the number is precise. The important parts remain uncertain: why it changed, whether it matters, and whether it will persist.

A useful insight keeps the exact observation, adds the strongest available context, labels any explanation as a hypothesis, connects the change to an outcome, and proposes the next check.

That is the difference between a chart rewritten as a sentence and analysis that helps someone decide.

I Published 31 DEV Posts. The One With 300 Views Got Zero Reactions.

Zenovay — Sat, 25 Jul 2026 12:42:48 +0000

I published 31 posts on DEV and collected 1,222 views.

My most-viewed post reached 300 views.

It got zero reactions and zero comments.

Another post reached only 47 views. It got 3 reactions and 5 comments.

That changed how I think about “a successful post.”

One post was a search engine

The 300-view article was an 11-minute Cloudflare architecture deep-dive.

It earned 112 views from Google and 20 from DuckDuckGo. Months later, people still find it because the title matches a specific technical problem.

But its average read time was 123 seconds.

It created discovery, not discussion.

The other post was a conversation

The 47-view article was about a problem I felt while using coding agents:

AI can write code faster than I can responsibly review it.

It had no tutorial and no giant code block. It had one tension, concrete examples, and a question readers could answer from their own experience.

Its average read time was 79 seconds. More importantly, people added ideas that improved the original argument.

I was optimizing one number to do two jobs

Search posts and discussion posts are different products.

A search post needs a precise problem, concrete implementation details, and enough depth to deserve the query.

A discussion post needs a sharp claim, a human consequence, and room for the reader to disagree.

The mistake is expecting one article to maximize both.

Now I want to alternate deliberately:

Discovery posts that answer one narrow technical question.
Discussion posts that expose one real decision or failure.

If you had to choose, which result would you rather publish: 300 views with no visible response, or 47 views that start a real conversation?

Disclosure: I used AI to help analyze my DEV dashboard, structure this post, and produce the visuals. I reviewed the source data, claims, and final draft.