Coder Legion - Recent posts tagged analytics

What Is a Good Conversion Rate? (And Why the Average Can Fool You)

Sat, 31 Oct 2026 13:43:31 +0000

We build Opti-Behavior, the WordPress plugin mentioned in this guide.

Imagine Nadia. She sells online yoga classes. Last month, 3,000 people visited her sales page and 45 bought a class. She typed "what is a good conversion rate" into Google and found an article that said "the average is 2.35%". Hers was 1.5%. She felt terrible.

Nadia is an example: her site and figures are made up to show the method step by step.

Then she found another article that said "a good conversion rate is 10%". Now she felt even worse.

Here is the truth: both articles were talking about other people’s websites. A good conversion rate depends on what you sell, who visits, and what you count as a conversion. In this guide we will work out a good rate for Nadia’s site, step by step, and then find ways to raise it.

Short answer: A good conversion rate is one that is better than your own rate last month, measured the same way. Industry averages are rough hints, not goals. Measure one clear action, per visitor, for each type of page, and improve the weakest step first.

What is a conversion, exactly?

A conversion is when a visitor does the thing you want. It can be big or small:

Type	Examples
Big (macro) conversion	A purchase, a paid sign-up, a booked call, a quote request
Small (micro) conversion	Adding to cart, starting a form, signing up to a newsletter, watching a demo

Small conversions matter because they lead to big ones. If nobody adds to cart, nobody buys.

How to calculate your conversion rate

The formula is simple:

Conversion rate = conversions ÷ visitors × 100

Nadia: 45 purchases ÷ 3,000 visitors × 100 = 1.5%.

But watch out. Tools do not all divide by the same thing:

Per visitor: 45 buyers out of 3,000 people. This is the honest one for sales.
Per session: 45 buyers out of 4,200 visits. The rate looks lower, because many people visit twice before buying.
Per page: conversions on one page divided by that page’s visitors. Best for comparing pages.

When you compare numbers, always use the same method. Many "benchmark" articles do not say which one they used.

So what is a good conversion rate?

Here are ranges you often see quoted in marketing reports. They come from different studies and change every year, so treat them as rough hints:

Type of page or site	Often quoted range
Online shop (all visitors)	1% to 3%
Shop, visitors who add to cart	30% to 60% reach checkout
Lead form on a service site	2% to 5%
Dedicated landing page from an ad	5% to 15%
Newsletter sign-up box on a blog	1% to 3%
Free trial sign-up (software)	3% to 10%

Why are the ranges so wide? Because a "good" rate depends on:

Price. A $5 ebook converts more than a $900 course.
Traffic source. Visitors from your newsletter already trust you. Visitors from a cold ad do not.
Device. Mobile visitors often browse and buy later on a computer.
Intent. Someone searching "buy yoga class online" is ready. Someone searching "is yoga good for back pain" is learning.

So Nadia’s 1.5% was not bad for a paid course with mostly cold traffic. The real question was: which part of her journey was weak?

Split the rate into steps

One big conversion rate hides where the problem is. Split the path into steps. This is called a funnel.

Nadia’s path was: Sales page, Pricing, Checkout, Thank-you page. In Opti-Behavior, you can create this funnel in a minute: go to Opti-Behavior > Funnels, click Build New Funnel, and add each step with a URL rule, like "URL Contains /pricing/". Opti-Behavior also suggests funnels built from the pages of your site.

Each step shows how many visitors continue and how many leave.

Here is what Nadia’s funnel showed:

Step	Visitors	Continue to next step
Sales page	3,000	28%
Pricing	840	22%
Checkout	185	24%
Thank-you	45

The big leak was at checkout: 185 people started to pay, only 45 finished. That is 76% lost at the very last step. Her sales page was fine. Her checkout was not.

With Pro, each funnel step links to the recordings of the people who left right there. Nadia watched eight of them. On phones, her checkout asked people to create an account with a password before paying. Most gave up at the password field.

In Pro, each step links to the recordings of the visitors who dropped there.

Measure what counts as a win

When you change something, you want to know if it worked. That is what A/B tests are for: half your visitors see the old version, half see the new one, at the same time.

In Opti-Behavior, a test has goals. The first goal is the one that picks the winner.

Goal	Counts a conversion when	Plan
Page visit	The visitor reaches a page, like a thank-you page	Free
Click	The visitor clicks an element you pick on the page	Free
Form submit	A form on the page is sent	Free
Scroll depth	The visitor scrolls to a depth you set	Pro
Time on page	The visit lasts longer than a threshold	Pro
Revenue	WooCommerce orders from the test	Pro

Pick the action that counts as a conversion. The first goal decides the winner.

The free version runs up to 3 tests at the same time, with up to 3 versions each.

Careful: a higher conversion rate is not always better

This surprises a lot of people. Look at this real-style example from our A/B testing docs:

Version	Visitors	Orders	Conversion rate	Average order	Revenue per visitor
A (current)	1,000	30	3.0%	60 €	1.80 €
B (free shipping over 50 €)	1,000	27	2.7%	78 €	2.11 €

Version B has a lower conversion rate, but people spend more, so it earns 17% more per visitor. If you only looked at the conversion rate, you would pick the wrong version. For shops, watch revenue per visitor too. Pro can measure it with a Revenue goal.

Know what one conversion is worth

Once you know the value of one conversion, every leak has a price. In Smart Insights settings, you can type the value of one conversion (Free and Pro). Smart Insights then estimates what a problem costs you. With Pro, WooCommerce orders set that value for you.

Type the value of one conversion, or, with Pro, let WooCommerce orders price the losses.

For Nadia, one class was worth 60 €. Losing 140 people at checkout every month was not "a bad conversion rate". It was up to 8,400 € a month walking away. That made the fix very easy to prioritize.

8 ways to raise your conversion rate

Fix the weakest step first. A 10% gain on your worst step beats a 10% gain on your best one.
Remove forced account creation. Let people buy as guests. Offer an account after payment.
Show the price and what is included early. Surprises at checkout kill sales.
Make the main button obvious. One clear action per page, visible without scrolling on mobile.
Answer doubts next to the button. Refunds, delivery time, support. One line each.
Speed up mobile. A slow checkout on a phone loses people fast.
Check for broken things. Rage clicks and JavaScript errors on a checkout page are pure lost money. Read our guide on rage clicks.
Test, do not guess. Run an A/B test on one change at a time. Our WordPress A/B testing guide shows how.

Nadia’s new conversion rate

Nadia allowed guest checkout and moved the account creation to the thank-you page. Six weeks later, 44% of people who reached checkout finished paying, instead of 24%. Her overall conversion rate went from 1.5% to 2.7%, with the same traffic.

She still does not know if 2.7% is "good" for the whole yoga industry. She does not care anymore. It is better than last month, and she knows exactly which step to work on next.

Find your weakest conversion step

Opti-Behavior is free: funnels, click heatmaps and A/B tests on WordPress. Pro adds drop-off recordings and revenue goals, with a 6-month free trial.

Good conversion rate FAQ

What is a good conversion rate?

It depends on your site, price and traffic. Rough ranges often quoted are 1% to 3% for online shops, 2% to 5% for lead forms and 5% to 15% for focused landing pages. The best benchmark is your own rate last month, measured the same way.

How do I calculate my conversion rate?

Divide the number of conversions by the number of visitors and multiply by 100. For example, 45 sales from 3,000 visitors is a 1.5% conversion rate.

Is a 2% conversion rate good?

For an online shop with mixed traffic, 2% is often considered solid. For a landing page that only receives ad visitors, it may be low.

Why is my conversion rate low?

Usually one step loses most people: an unclear offer, a hidden button, a surprise cost, a long form or a broken checkout. A funnel shows which step, and recordings show why.

Should I trust average conversion rate benchmarks?

Only as a rough hint. Studies measure different sites in different ways. Track your own rate per page and per step, and try to beat it.

The Opti-Behavior Team

Full guide: https://optiuser.com/go/coderlegion-conversion-rate

Drafted with AI assistance, reviewed by the Opti-Behavior Team.

LifeOps Project (Part 6): 360° Analytics Dashboard with Multi-Dimensional Filtering, Recharts and Co

Wed, 28 Oct 2026 08:18:20 +0000

In Part 5 of our engineering series, we achieved a major milestone: deploying the entire LifeOps architecture 24/7 in production at zero cost ($0/month) by combining Netlify, Render, and Supabase, optimizing mobile ergonomics for smartphones, and installing the app as a native PWA.

However, once you start logging dozens of daily activities (workouts, bike rides, books read, movies watched, and Kanban tasks), a critical analytical challenge emerges: data without analysis lacks operational value.

Having 40 or 50 records in a PostgreSQL database is of little use if opening the dashboard doesn't immediately answer operational questions such as:

“How many kilometers did I run this month compared to last month?”
“What percentage of my training went into sprint intervals versus long endurance runs?”
“How has my daily consistency evolved, and what is my current active day streak?”
“How can I filter exclusively by Running to inspect average pace and calories burned without mixing in gym workouts or movies?”

In this sixth installment, we tackle the full evolution of the 360° Analytics Dashboard, addressing both the deterministic client-side aggregation design and the most notorious UX challenge of zero-cost serverless infrastructure: cloud container sleep periods (cold-starts).

💡 Try the analytics live: You can test the new 360° Dashboard with interactive data in Sandbox mode at https://datalaria.com/apps/lifeops/#/?mock=true&lang=en or log in with your Supabase account at https://datalaria.com/apps/lifeops/#/?lang=en.

1. Architecture Decision: External BI (Grafana / Metabase) vs. Native React Engine (ADR-013) ⚖️

When planning advanced charts and timeframe filters, the first engineering instinct is often to reach for established Business Intelligence tools like Grafana, Metabase, or Apache Superset. However, evaluating our requirements against our project constraints led to architectural decision ADR-013:

Evaluation Factor	External BI Tool (Grafana / Metabase)	Native React 19 + Recharts 3.10 Engine (Our Choice)
Multi-Tenant Security (RLS)	❌ Requires static direct database connection. Passing individual Supabase Auth JWTs requires expensive Enterprise licenses or custom proxy tokens.	✅ Perfect Isolation: consumes secure user-scoped REST endpoints protected by Row-Level Security (`auth.uid() = user_id`).
Infrastructure Cost	❌ Requires a separate container running 24/7 with dedicated RAM, or paid cloud plans.	✅ $0.00/month: compiles directly into the Netlify static bundle.
Sandbox Demo Mode (`?mock=true`)	❌ Impossible to feed an external iframe using in-memory mock state.	✅ 100% Compatibility: runs instantly with deterministic synthetic data.
Filter Latency	⚠️ Every click triggers a remote SQL round-trip to the cloud.	✅ 0 ms: the timeframe dataset filters in client memory using pure `useMemo` hooks.
Mobile UX & Aesthetics	⚠️ Visual disconnect from Glassmorphism Dark Mode and nested iframe scroll friction on mobile.	✅ Unified Design: seamless responsive layout tailored to our design system.

Data Flow Architecture

API Layer: FastAPI REST API / Supabase PostgreSQL (GET /api/v1/activities/details?limit=200).
Local Cache: Stale-While-Revalidate (SWR) cache in localStorage (lifeops_swr_v1:<user_id>).
Client Engine: Deterministic Client Analytics Engine (lib/analyticsEngine.js).
Control Bar: Timeframes (7D, 30D, Month, 90D, Year), period comparisons (vs. prev.), and category/subcategory drill-downs.
Visual Suite: 4 dynamic KPI cards with Δ%, multi-metric ComposedChart time-series, PieChart donut breakdowns, and a 16-week consistency heatmap.

2. Multi-Dimensional Cascading Filters & Period-over-Period Deltas ⏱️📊

The cornerstone of the new experience is the Analytics Control Bar, enabling three levels of analytical exploration without page reloads:

A. Timeframe Resolution

The engine supports five time horizons powered by the deterministic resolveTimeWindows() function:

7 Days (week): Rolling last 7 days vs. immediately preceding 7 days.
30 Days (month): Rolling last 30 days vs. immediately preceding 30 days.
By Month (calendar_month): Dynamic month selector (January to December) and year, compared against the preceding calendar month.
90 Days (quarter): Rolling last 90 days aggregated into weekly buckets.
By Year (year): Full annual overview with 12 monthly buckets vs. prior year.

B. Invariant INV-8: Safe Percentage Delta Calculation (Δ%)

To compare current performance (V_curr) against the previous period (V_prev) without division-by-zero errors when starting a new discipline:

If V_prev = 0 and V_curr = 0 → Δ% = 0% (Stable).
If V_prev = 0 and V_curr > 0 → Δ% = +100% (Baseline creation).
In any other case → Δ% = round(((V_curr - V_prev) / V_prev) * 100).

export function computeDelta(currentVal, prevVal, unit = '', language = 'en') {
  const curr = Number(currentVal) || 0;
  const prev = Number(prevVal) || 0;
  const vsLabel = language === 'es' ? 'vs. ant.' : 'vs. prev.';

  if (prev === 0 && curr === 0) {
    return { positive: true, deltaPct: 0, text: 'Stable (0% vs. prev.)' };
  }
  if (prev === 0 && curr > 0) {
    return { positive: true, deltaPct: 100, text: `+100% (+${curr}${unit} ${vsLabel})` };
  }

  const diff = curr - prev;
  const pct = Math.round((diff / prev) * 100);
  const sign = diff >= 0 ? '+' : '';
  return {
    positive: diff >= 0,
    deltaPct: pct,
    diff,
    text: `${sign}${pct}% (${sign}${diff.toFixed(1)}${unit} ${vsLabel})`,
  };
}

3. The Visual Suite with Recharts: Contextual KPIs, Time-Series & Donut Charts 📈🍩

Selecting a category or drilling down into a subcategory (for example, filtering by Sport ➔ Running) dynamically updates the entire dashboard:

4 Contextual KPI Cards:
- In Sport: adapt metrics to the selected discipline:
  - Sessions: workout count with Δ% badge and personal bests (PB).
  - Distance: cumulative mileage and average km per session.
  - Time & Pace: active duration and average pace (min/km in running or km/h in cycling).
  - Calories & Effort: calories burned, average heart rate (bpm), and elevation gain (+m).
Multi-Metric Time-Series Chart (ComposedChart):
- Renders current period bars color-coded by category and overlays a dashed trendline of the previous period when the ⇄ Compare vs. prev. toggle is active.
- Built-in metric switcher: toggle on the fly between Sessions, Distance (km), Calories (kcal), Duration (h), or Elevation Gain (m).
Subcategory Distribution (PieChart Donut):
- Displays percentage and absolute shares for each activity type. Clicking any slice or legend item applies an automatic drill-down into that subcategory.

4. 16-Week Consistency Daily Heatmap (Strava / GitHub Style) 🔥🗓️

Habit formation and athletic progression rely on consistency. To provide clear visual accountability, we built a 112-day grid (16 weeks × 7 days, Monday to Sunday):

The algorithm evaluates daily activity volume across 5 intensity tiers (level-0 to level-4) and computes in real time:

Active days during the evaluated window.
Current active streak: counting consecutive active days backwards from today or yesterday.
All-time best streak.

5. Overcoming the Free-Tier Cloud UX Challenge: Cold-Start Mitigation ⚡🛡️

Deploying full-stack web applications on free cloud tiers (such as Render.com's Free Web Service) introduces an unavoidable reality: the container sleeps after 15 minutes of inactivity.

When a user visits after several hours, the initial request takes 20 to 40 seconds while the virtual machine boots. In early versions, this lag produced a terrible UX: users saw blank charts and KPI cards showing 0, leading them to believe their data was lost or deleted.

To eliminate this friction while staying strictly within our $0.00/month budget, we engineered a 3-layer mitigation system:

Layer 1: Silent Pre-Warming (`wakeUpServer`)

The moment the browser loads the SPA inside AuthContext.jsx—before the user even finishes entering credentials or navigating to the Dashboard—a non-blocking background fetch pings /health. This gives the container a 5-to-10 second head start to spin up.

Layer 2: User-Scoped Stale-While-Revalidate (SWR) Local Cache

Every read request (GET /api/v1/activities/details, /tasks, /stats/dashboard) is cached in localStorage under a strict user-prefixed key (lifeops_swr_v1:<user_id>:<endpoint>).

On subsequent visits, cards and charts hydrate in under 10 milliseconds (effectively 0 ms).
The user sees their data immediately while background network calls fetch fresh updates.
Any write operation (POST, PATCH, DELETE) automatically invalidates the local cache to guarantee consistency.

If a user accesses the app from a clean browser and must wait through a cold start:

Never show misleading zeros: KPI cards display waiting indicators (···) instead of 0.
Transparent Status Banner: displays an animated spinner, live elapsed seconds counter (0s, 1s, 2s...), visual progress bar, and active phase badges:
- ✓ Authenticated Session (Supabase Auth)
- ⟳ Waking API Engine on Render Cloud
- ⏳ Hydrating Activities & 360° Analytics
If the wait exceeds 4 seconds, the banner explicitly explains that the free cloud container is spinning up and that all data is 100% safe.
Automatic Timeframe Fallback: if the query returns activities but none fall within the last 30 days (e.g. after a vacation), the dashboard automatically switches to 90 Days or By Year so charts appear populated immediately.

6. Conclusions & Links 🚀

With this update, LifeOps evolves from a plain activity logger into a full personal operations intelligence system. Combining deterministic client-side analytics with a resilient cold-start mitigation architecture proves that it is entirely possible to build fast, secure, and visually stunning software on a $0.00/month infrastructure bill.

🎮 Deployed Web App: https://datalaria.com/apps/lifeops/
🕹️ Interactive Sandbox Mode (No Registration): https://datalaria.com/apps/lifeops/#/?mock=true&lang=en
📋 Official LifeOps Technical Overview: https://datalaria.com/en/apps/lifeops/

If you enjoyed this technical breakdown, explore more open engineering articles and quantitative apps at www.datalaria.com.

What Is a Good Bounce Rate? Ranges by Page Type and When to Worry

Tue, 27 Oct 2026 13:38:17 +0000

We build Opti-Behavior, the WordPress plugin mentioned in this guide.

You open your analytics. Bounce rate: 68%. Is that a good bounce rate, and how do you reduce bounce rate when it is not?

The honest answer: it depends on the page. A blog post and a checkout page have very different jobs. A bounce rate that is great for one is terrible for the other.

This guide explains what a good bounce rate is for each kind of page, why a high number is sometimes fine, and how to find the real reason people leave.

What is a bounce, exactly?

In simple words, a bounce is a visit where the person arrives and leaves without doing much.

But "without doing much" means different things in different tools:

Old Google Analytics (Universal Analytics): a bounce was a visit with only one page view. Someone who read your article for 10 minutes and left still counted as a bounce.
GA4: a bounce is a visit that is not engaged. A visit counts as engaged if it lasts more than 10 seconds, or has two or more page views, or includes a conversion. So GA4 bounce rate is simply 100% minus the engagement rate.

That is why your bounce rate probably dropped when you moved to GA4. The visitors did not change. The definition did.

Tip: When you compare your bounce rate with any "average", first check which definition it uses.

Good bounce rate ranges by page type

These are broad ranges often seen across websites, using the "one page, short visit" idea. Treat them as a starting point, not a rule.

Page type	Typical range	Why
Blog post or article	65% to 90%	People read one article and leave. That is normal.
Landing page (one offer)	60% to 90%	One page, one action. No reason to click deeper.
Home page	40% to 60%	It should send people to other pages.
Product page (e-commerce)	30% to 55%	People compare, add to cart, look at other products.
Service or lead-gen page	35% to 60%	Visitors check prices, reviews, contact.
Checkout or cart	Under 30%	Leaving here usually means a problem.

When a high bounce rate is fine

The page answered the question. Someone searched "store opening hours", found them, left happy.
It is a single-page site or landing page. There is nowhere else to go.
The goal is off-site. A click to call, to an app store, or to a partner.
Long reads. In old-style analytics, a 10-minute reader who leaves is still a bounce.

When a high bounce rate is a problem

Visitors leave fast (under 10 seconds). They did not find what they expected.
Paid traffic bounces. You pay for each visit, so every quick exit costs money.
Pages that should lead somewhere (home, category, pricing) have a very high rate.
Mobile is much worse than desktop. Something is broken or slow on phones.

How to find out why people bounce

The bounce rate tells you that people leave. It never tells you why. For that you need to look at behavior.

Scroll heatmap. Do people even reach your main content? If 70% stop at the hero, the top of the page is the problem. (Pro in Opti-Behavior)
Click heatmap. Are people clicking on something that is not a link, then giving up?
Session recordings. Watch 5 to 10 visits that ended quickly. You will often spot the reason in minutes. (Pro in Opti-Behavior)
Speed on real visitors. A slow page on mobile is one of the most common causes of quick exits.

In Opti-Behavior, the Traffic dashboard shows your bounce rate and average scroll depth. Click heatmaps are free; scroll heatmaps and session recordings are in Pro. Smart Insights (Free) then turns your traffic, click and funnel data into one card per problem (Pro adds signals from recordings, scroll heatmaps, errors and forms): what is wrong, where it happens, the evidence behind it and what to check next.

7 ways to lower a bad bounce rate

Match the promise. The page must deliver what the ad or search result said.
Say what you offer in the first screen. One clear headline, one sentence, one button.
Speed up mobile. Compress the hero image, remove heavy widgets.
Remove pop-ups that fire right away. Let people read first.
Add clear next steps. Related articles, "see pricing", a visible button.
Make text easy to scan. Short paragraphs, headings, bullet lists.
Test your changes. An A/B test tells you if the new version really keeps people longer.

A good bounce rate: the bottom line

A good bounce rate is the one that fits the page’s job. Compare each page with itself over time, not with a random average. When a page that should lead somewhere starts to bounce more, look at its heatmap and a few recordings before you change anything. Our guides on adding a heatmap to WordPress and form abandonment show the next steps.

Good bounce rate FAQ

What is a good bounce rate?

It depends on the page. Very roughly, 30% to 55% is common for product pages, 40% to 60% for home pages, and 65% to 90% is normal for blog posts and landing pages.

Is a 70% bounce rate bad?

Not for a blog post or a landing page. It can be a warning sign for a home page, a product page or a checkout.

Why did my bounce rate drop in GA4?

GA4 counts a visit as a bounce only if it is not engaged (under 10 seconds, one page, no conversion). Universal Analytics counted every one-page visit, so GA4 numbers are usually lower.

How do I lower my bounce rate?

Find out why people leave with click heatmaps (free), scroll heatmaps and recordings (Pro), then fix the first screen, the speed on mobile and the next step you offer. Test the change with an A/B test.

The Opti-Behavior Team

Full guide: https://optiuser.com/blog/what-is-a-good-bounce-rate/?utm_source=coderlegion&utm_medium=referral&utm_campaign=oct26-problem-keyword&utm_content=good-bounce-rate

Drafted with AI assistance, reviewed by the Opti-Behavior Team.

I let every AI crawler in. A month later I cannot tell you how many people read me.

Mon, 26 Oct 2026 01:32:09 +0000

In early August Cloudflare sent me a congratulations email. The site had passed ten thousand pageviews in its first month: 33,561, on a domain that went live on 5 July.

For about ten seconds it was good news.

Then I remembered what I had done in July, which was open robots.txt to every AI crawler in existence. Training included, on purpose. I have no brand to protect and my problem is not that someone copies me: it is that nobody finds me. So everyone gets in.

Which makes that number, taken as it is, good for nothing.

Why does a pageview count not tell you how many people read you?

Because Cloudflare's free plan counts requests, not people, and it does not separate humans from bots. Inside those 33,561 are the crawlers I invited myself, and I have no way to know in what proportion.

This is a practical problem, not a philosophical one. If a client asks me tomorrow how much traffic the site gets, I do not have an answer I can defend. "Thirty-three thousand" would be a true sentence and false information, because whoever hears it understands "thirty-three thousand people". I would rather say I do not know.

And there is the opposite question, which matters more to me: is opening the gates working? If GPTBot comes through and re-reads the site every week, I did the right thing. If it never comes, I am giving away bandwidth for nothing, and I would like to know.

Is letting AI crawlers in actually worth it?

On half the question I have a measured answer, and the two halves look nothing alike. Perplexity cites me in first position for "who is Marco Bellingeri, cloud and security engineer". ChatGPT, asked the same thing, does not cite me at all.

The monitor that measures this runs every Monday and writes the history to a database. So far, routine. The interesting part is what the model did when I asked it that question.

It did not look for me. It rewrote the question into a search query, "Marco Bellingeri AI security", and read twelve pages about the topic: the European regulation, the AI Act, the Bletchley declaration, a couple of newspapers. None of them was about a person. It answered about the subject because it never found the person.

That is a different kind of failure from "your content is not good enough". It is the engine failing to connect the question to the page, and the difference changes what is worth doing next. If the crawler never comes, rewriting articles is wasted time and the problem is access. If it comes and does not cite, the problem is that the content is not extractable, and then rewriting is the work.

To know which, I needed to count who comes through.

How do you count crawlers without tracking people?

By looking at the User-Agent of every page request and recording only the family it belongs to, with no IP address, no cookie, no session, nothing that ties two requests to the same person.

The site is static and runs on Cloudflare Workers, so the Worker was the obvious place. I started from an assumption that turned out to be false: I thought every request went through it. It did not. The Worker was configured to run on five routes only, the root and four APIs. Every page of the site was served straight from static assets, and my code never saw a thing.

The fix was not "send everything through". Requests to static assets are free and unlimited; requests that invoke the Worker consume the free plan's quota of a hundred thousand a day. Sending everything through would have put my code in front of every font and every stylesheet, which is most of the volume and all of the latency that matters, in order to count things that are not pageviews.

So only HTML goes through. A pageview is an HTML request. The rest is what that page drags along with it.

What NOT to keep, which is the hard part

The classification is trivial: a list of names, GPTBot, ClaudeBot, PerplexityBot, Googlebot, and a couple of rules to spot a real browser. Twenty lines. What took me time was deciding what to throw away.

A browser's User-Agent identifies a person far more than it looks. Combined with other signals it becomes a fingerprint. So for a person I keep one word, human, and drop the string.

For a crawler I already know I keep the family name and nothing else: I know who it is, the rest adds nothing.

That leaves the awkward case, the one that made me rewrite the code twice. If I do not recognise the client, what do I do? The first version called it a bot and kept its full User-Agent. Wrong on two counts. The first is that a person can be in there: a text browser, a webview inside an app, an accessibility tool, a User-Agent stripped by a privacy extension. Treating them as a bot and keeping their string is exactly the thing I said I would not do.

The second reason is that the number lies. If I put "a crawler I do not recognise" and "I could not tell what this was" in the same bucket, I then read that forty per cent of the traffic is automated and believe it, when part of that forty is my own uncertainty wearing a certainty's clothes. And that number is the one that ends up in front of a client.

Now there are two labels. A client that declares itself automated in its own User-Agent, by writing bot or crawler or curl into it, gets kept as its short product name: that is what lets me notice a new family. A client that simply does not place gets recorded as unclassified and nothing else.

What does counting cost?

Little, but not nothing, and the point is knowing beforehand rather than finding out. Every page that goes through the Worker consumes one request of the free quota. At today's traffic that is around eleven hundred a day against a hundred thousand: a margin of about ninety, which is comfortable but not infinite, and there is no rate limit on those routes.

I wrote it into the project README, along with what I will do if the number gets close, in order: watch the counter, narrow the routes and accept counting less, and only then pay. A declared ceiling with an exit path next to it is acceptable debt. A ceiling discovered by accident one night is an incident.

The line that nearly made me publish a lie

My site's privacy policy said, in Italian and in English, that it "uses no tracking or analytics".

That was true until the day before. If I had shipped the counter without touching that page, the site that sells transparency would have published a false statement about itself, and no test would have caught it: tests look at code, not at promises.

I rewrote it before shipping. It now says what it does: it counts requests one at a time, with no identifiers, no profiling, and keeps the data for three months because that is when the platform deletes it. I also removed the word "aggregate" from a first draft, because it was not true: what I write is one event per request, not a running total, and calling it aggregate would have been more reassuring and less accurate.

What I still do not know

The counter has been on for a few hours. I generated the first data points myself, sending three test requests with fake User-Agent strings to check that it worked, and honestly I could not tell them apart from real traffic.

So I have nothing to tell you about crawlers yet. In a week I will know: which families come through, how often, on which pages, and above all whether GPTBot shows up at all. That answer decides whether it is worth continuing to write to be found by a model, or whether I have been writing for an audience that never came.

In the meantime I have lost the ability to say thirty-three thousand. It looks like a step backwards and it is a real step forward: before, I had a big number and no idea what was inside it. Now I have a measurement on its way, and in the meantime an honest answer.

What 1.23M Edge Requests Taught Us About AI Crawlers (and Our Own Analytics)

Tue, 20 Oct 2026 11:36:46 +0000

Originally published on SEOSiri.

We read 90 days of Cloudflare edge logs through Microsoft Clarity's bot analytics (~1.23M requests) and compared them with GA4 and Blogger stats. Here's what stood out, with the caveats.

The split

About 70% of requests were likely human, about 30% automated.
Clarity classifies roughly 200K requests as AI crawler, AI search or AI assistant activity.

Selected AI operators (requests in 90 days)

Operator	Requests
Microsoft	43,380
Google	42,050
Meta	35,690
Anthropic	19,730
OpenAI	14,900

Clarity also lists Huawei and Amazon above OpenAI. Logs show who asked for a page, not how the data is used afterward.

robots.txt compliance

Clarity's Violations card showed 0.98%: requests to URLs our robots.txt disallows. That's a compliance metric, not a security one. If you set per-operator rules, they look like this (choose Allow or Disallow for your own policy):

User-agent: GPTBot
Allow: /

User-agent: ClaudeBot
Allow: /

Status codes

Around 48% of requests showed as unsuccessful in Clarity. We're breaking them down by path and status code next.

Don't mix units

Blogger showed 64.7K pageviews from the Netherlands. GA4 showed 102 active users there. Same site, same 90 days, different measures.

How do you separate bots from humans in your analytics?

Full write-up with tables and methodology: SEOSiri edge telemetry audit

SEOSiri is my own property

Heatmap Empty After Installing a Cache Plugin? 3 Checks in 60 Seconds

Tue, 13 Oct 2026 22:27:08 +0000

Your heatmap is empty, the session counter says zero, and nothing errors. On WordPress, the usual cause is not the analytics tool. It is the cache or performance plugin: it merges, defers or delays JavaScript, and the tracker stops running without a single warning. This applies to every tool in the category (Hotjar, Microsoft Clarity, Matomo, Opti-Behavior or your own beacon).

Open your site in a private window, logged out, and run these three checks in order.

1. Is the script in the HTML?
View source (Ctrl+U, not the Elements tab) and search for your tracker's file name.

Not there: the script was never added. Check the plugin is active and that you are not excluded as a logged-in admin.
src points to something like /wp-content/cache/min/...: the tracker was merged into a bundle.
type is not text/javascript (for example rocketlazyloadscript): the script is delayed until the first interaction.

2. Does the request leave the browser?
DevTools > Network > Fetch/XHR, then click and scroll for ten seconds.

No request: the tracker never started.
4xx: often an expired nonce on a page served from cache for too long.
200: tracking works; look at filters or admin exclusion instead.

3. Is the config object defined?
In the console, type your tracker's global config name. undefined while the file is present means the small inline config block was optimised away. Excluding the file is only half the job: the inline block needs its own exclusion rule.

The full guide has the exclusion code for WP Rocket, LiteSpeed Cache, SiteGround Optimizer, Autoptimize, Perfmatters, WP-Optimize, W3 Total Cache, Breeze and Jetpack Boost, plus a clean way to verify the fix:
https://optiuser.com/blog/heatmap-not-working-cache-plugin/?utm_source=coderlegion&utm_campaign=traffic-oct26

Disclosure: written by The Opti-Behavior Team, the publisher of the Opti-Behavior plugin, with the help of AI tools, and reviewed by the team.

Telemetry: Shared Analytics and Crash Reporting in Kotlin Multiplatform

Fri, 09 Oct 2026 14:00:00 +0000

In a modern endurance car, every sensor talks to the same box. Tyre pressure, brake temperature, fuel flow, throttle trace. They all end up in one data stream that goes to the pit wall over a single radio link. The engineer on the wall doesn't care which supplier made the brake sensor. He cares that the channel is called BRAKE_TEMP_FL and that the number arrives every 100 milliseconds.

Swap a sensor, the channel name stays. That's the whole point of the standard.

Analytics and crash reporting in a KMP app should work the same way. The sensors are the SDKs, one per platform, made by different teams with different APIs. The channel names are yours.

What I had before

My first KMP app logged analytics twice. Once in Kotlin for Android, once in Swift for iOS. Same events, same names, in theory.

In practice, the Android side sent screen_view with a screen_name parameter. The iOS side sent screenView with screenName. Nobody noticed for six weeks, until I tried to build a funnel in the dashboard and half the users were missing from it. The numbers weren't wrong. They were split across two event names that meant the same thing.

That's the real cost of leaving telemetry in the platform layer. Not the duplicated code, which is small. The drift. Two implementations of the same contract, with no compiler checking that they agree.

If you read Change the Map, this is the same move applied to a different problem: the contract lives in commonMain, the SDKs sit underneath. It also pairs with flags directly, because the first event worth logging is which variant a user was actually shown.

Crash reporting has a quieter version of the same problem. A Kotlin exception that crashes the Android app shows up in Crashlytics with a readable stack trace. The same exception on iOS arrives as a native crash with frames that look like kfun:..., and the Kotlin type is buried in the message. I'll get to that.

The interface lives in commonMain

The fix is to stop treating analytics as a platform feature and start treating it as a domain contract.

// commonMain
interface Analytics {
    fun track(event: AnalyticsEvent)
    fun setUserId(id: String?)
}

sealed interface AnalyticsEvent {
    val name: String
    val params: Map<String, String>

    data class ScreenView(val screen: String) : AnalyticsEvent {
        override val name = "screen_view"
        override val params = mapOf("screen_name" to screen)
    }

    data class Purchase(val sku: String, val amountCents: Long) : AnalyticsEvent {
        override val name = "purchase"
        override val params = mapOf(
            "sku" to sku,
            "amount_cents" to amountCents.toString(),
        )
    }
}

A sealed interface for events is the part that pays for itself. The event name and the parameter keys exist in exactly one place. A new event is a new class, and the compiler tells every when that cares about it. A typo in "screen_name" is no longer possible in two files, because it's only written once.

I keep params as Map<String, String> on purpose. Firebase, Mixpanel, and Amplitude all accept richer types, but they disagree about which ones. Strings are the lowest common denominator, and the conversion cost is trivial.

The crash side is a second, separate interface.

// commonMain
interface CrashReporter {
    fun log(message: String)
    fun recordNonFatal(throwable: Throwable)
    fun setUserId(id: String?)
}

Two interfaces, not one. Analytics is about what users did. Crash reporting is about what broke. They often go to different vendors, and you'll want to swap one without touching the other.

Android: the easy side

On Android the implementation is a thin wrapper. Firebase is the obvious choice, though nothing here is Firebase-specific.

// androidMain
class FirebaseAnalyticsImpl(
    private val firebase: FirebaseAnalytics,
) : Analytics {

    override fun track(event: AnalyticsEvent) {
        val bundle = Bundle().apply {
            event.params.forEach { (k, v) -> putString(k, v) }
        }
        firebase.logEvent(event.name, bundle)
    }

    override fun setUserId(id: String?) {
        firebase.setUserId(id)
    }
}

class CrashlyticsReporter(
    private val crashlytics: FirebaseCrashlytics,
) : CrashReporter {

    override fun log(message: String) = crashlytics.log(message)

    override fun recordNonFatal(throwable: Throwable) =
        crashlytics.recordException(throwable)

    override fun setUserId(id: String?) {
        crashlytics.setUserId(id.orEmpty())
    }
}

Nothing clever. If the Android side is the only one you ever shipped, this is the code you already had.

iOS: the Swift bridge

The simplest iOS implementation doesn't call the Firebase iOS SDK from Kotlin at all. No expect/actual in this layer, no cinterop bindings, no CocoaPods dependency in the shared module.

The shared module defines the interface, and the iOS app passes in a Swift implementation at startup.

// iosApp
final class FirebaseAnalyticsBridge: Analytics {

    func track(event: AnalyticsEvent) {
        FirebaseAnalytics.Analytics.logEvent(event.name, parameters: event.params)
    }

    func setUserId(id: String?) {
        FirebaseAnalytics.Analytics.setUserID(id)
    }
}

Swift sees the Kotlin interface as a protocol, so conforming to it is ordinary Swift. The one snag is the name: Firebase's Swift class is also called Analytics, so inside this file the bare name is ambiguous. I qualify the Firebase one with its module. Renaming the Kotlin interface would also work, but I'd rather not let a vendor pick my names. The app registers it with the DI container before the first screen renders.

// commonMain/Telemetry.kt
fun setUpTelemetry(analytics: Analytics, crashReporter: CrashReporter) {
    // register both in your DI graph of choice
}

// iosApp
@main
struct IosApp: App {
    init() {
        TelemetryKt.setUpTelemetry(
            analytics: FirebaseAnalyticsBridge(),
            crashReporter: CrashlyticsBridge()
        )
    }
    // ...
}

I don't start that function name with init. The Objective-C export reserves init for initializers, so a Kotlin function called initTelemetry shows up in Swift as doInitTelemetry. It works, but it's the kind of thing that costs ten minutes the first time you see it.

The Firebase SDK stays where Xcode manages it. The shared module never learns it exists.

Two other ways to bring the SDK in

That Swift bridge is how I wrote this in my first KMP apps, and it's the version I'd explain to anyone starting out because every moving part is visible. It isn't what I use today.

GitLive's Firebase Kotlin SDK. firebase-kotlin-sdk from GitLive wraps Firebase so you can call it from commonMain. I haven't shipped it myself. If you use it, your Analytics interface still sits in front of it, otherwise you've just moved the vendor lock-in into shared code.

CocoaPods through Gradle, with the call in iosMain. This is what I use now. The Kotlin CocoaPods plugin lets the shared module declare the Firebase pod itself, and Kotlin generates the bindings so iosMain can call the iOS SDK directly.

// build.gradle.kts (shared module)
plugins {
    kotlin("multiplatform")
    kotlin("native.cocoapods")
}

kotlin {
    cocoapods {
        version = "1.0"
        ios.deploymentTarget = "16.0"
        pod("FirebaseAnalytics")
        pod("FirebaseCrashlytics")
    }
}

You can pin a version with pod("FirebaseAnalytics", "~> 12.0"), and linkOnly = true exists for pods you only need to link and not bind. The Kotlin docs cover both.

Then the iOS implementation is Kotlin, in the same module as the interface.

// iosMain
import cocoapods.FirebaseAnalytics.FIRAnalytics
import kotlinx.cinterop.ExperimentalForeignApi

@OptIn(ExperimentalForeignApi::class)
class IosAnalytics : Analytics {

    @Suppress("UNCHECKED_CAST")
    override fun track(event: AnalyticsEvent) {
        FIRAnalytics.logEventWithName(event.name, event.params as Map<Any?, *>)
    }

    override fun setUserId(id: String?) {
        FIRAnalytics.setUserID(id)
    }
}

The bindings come from the Objective-C headers, not the Swift API, so the class is FIRAnalytics and the method is logEventWithName. The parameters dictionary arrives as Map<Any?, *>?. A Map<String, String> doesn't fit that type as-is, because map keys are invariant in Kotlin, hence the cast.

I switched because the Swift bridge had a cost I only noticed over time: two files per interface, in two languages, in two repos' worth of mental context. With the pod declared in Gradle, the iOS implementation sits next to the Android one, in Kotlin, and a new method on Analytics fails the build in the same module.

It has its own cost. Pod dependencies and cinterop bindings are now part of your shared module's build, so Gradle sync and iOS builds feel it, and a Firebase SDK bump can break the generated bindings. It's also the option with an expiry date: the Kotlin docs now carry a CocoaPods-to-SwiftPM migration guide, and the new swiftPMDependencies { } block replaces cocoapods { }. The docs I read put the minimum Kotlin Gradle plugin at 2.4.20-RC3 for it, so check your version before planning the move. That's the trade I accept for keeping everything telemetry-related in one language.

I'm showing three options on purpose, and Firebase is only the example. A KMP project has more than one way to bring a native dependency in: a bridge the app injects, a KMP wrapper library, or a native dependency declared in Gradle. Which one fits depends on how much of the native SDK surface you need, and who maintains the glue.

Kotlin exceptions on iOS are not Kotlin exceptions

This is the part nobody mentions until you're staring at a dashboard.

When an uncaught Kotlin exception terminates the app on iOS, the crash is reported by the native crash handler. The stack trace is the native one. The Kotlin frames are there, but unsymbolicated Kotlin frames read as noise, and the exception type is flattened. Touchlab's CrashKiOS exists for exactly this: it sends symbolicated Kotlin crashes and handled exceptions to Crashlytics, with breadcrumbs and custom keys. Its docs page was last updated in January 2024, so check the repo for recent activity before you rely on it.

For non-fatal errors you have a better option. Catch the exception at a boundary you control, and hand it to recordNonFatal. On iOS that means converting it to an NSError, and that's where it gets fiddly.

Swift can't get much out of a KotlinThrowable by itself. The Kotlin stack trace accessor on Native, getStackTrace(), is a stdlib extension marked @ExperimentalNativeApi, so I don't count on it being reachable from Swift. I let Kotlin do the work instead, with two small extensions in iosMain.

// iosMain
fun Throwable.kotlinTypeName(): String =
    this::class.qualifiedName ?: "UnknownKotlinThrowable"

fun Throwable.kotlinStackTrace(): String = stackTraceToString()

They extend a Kotlin class, so the export turns them into methods on KotlinThrowable and Swift calls them like any other method.

// iosApp
final class CrashlyticsBridge: CrashReporter {

    func recordNonFatal(throwable: KotlinThrowable) {
        let error = NSError(
            domain: throwable.kotlinTypeName(),
            code: 0,
            userInfo: [
                NSLocalizedDescriptionKey: throwable.message ?? "unknown",
                "kotlin_stacktrace": throwable.kotlinStackTrace(),
            ]
        )
        Crashlytics.crashlytics().record(error: error)
    }

    func log(message: String) {
        Crashlytics.crashlytics().log(message)
    }

    func setUserId(id: String?) {
        Crashlytics.crashlytics().setUserID(id ?? "")
    }
}

Crashlytics turns userInfo into key-value pairs in the keys section of the issue, so the full Kotlin trace sits right there. I put it there on purpose rather than hoping the dashboard parses the message, because it won't.

The domain choice matters more than it looks. For fatal crashes Crashlytics groups by stack trace, but the Firebase docs say logged errors are grouped by domain and code. A fixed domain like "kotlin" with code 0 would collapse every non-fatal into one issue. With the Kotlin type there, an IllegalStateException and a network timeout stay separate. Keep unique values like user IDs or timestamps out of both fields, or you'll fragment the dashboard the other way. Crashlytics also only stores the most recent eight exceptions in a session, so recordNonFatal is not a log.

Where the calls go

The interface is only worth having if people use it in the same place. I let ViewModels own analytics events and nothing else.

// commonMain
class CheckoutViewModel(
    private val analytics: Analytics,
    private val crashReporter: CrashReporter,
    private val repository: CheckoutRepository,
) : ViewModel() {

    fun onPay(sku: String, amountCents: Long) {
        viewModelScope.launch {
            runCatching { repository.pay(sku, amountCents) }
                .onSuccess {
                    analytics.track(AnalyticsEvent.Purchase(sku, amountCents))
                }
                .onFailure {
                    if (it is CancellationException) throw it
                    crashReporter.recordNonFatal(it)
                }
        }
    }
}

The CancellationException check is there because runCatching catches it too. Without it, every user who leaves the screen mid-payment becomes a non-fatal in Crashlytics.

Composables and SwiftUI views don't call track. Screen views are the exception, and I fire them from a single navigation observer, so there's one line of code that produces every screen_view in the app.

The other benefit shows up in tests. A FakeAnalytics that stores events in a list takes ten lines, and asserting on it in commonTest is trivial. I used to skip testing analytics because it meant mocking an SDK. Now I assert that tapping Pay produces exactly one Purchase with the right amount, and it runs on every target.

Gotchas

Don't init the SDKs inside commonMain, whichever option you pick. Firebase on Android wants a Context. On iOS it wants FirebaseApp.configure() before anything else touches it. Those calls belong in Application.onCreate and the iOS App.init, not behind an abstraction that pretends the platforms are the same.

User IDs are a privacy decision, not a plumbing one. setUserId is easy to wire and easy to get wrong. I pass an internal opaque ID and never an email. Deciding that once, in the interface docs, beats hoping every caller remembers.

Consent has to be a gate, not a flag. If your users can opt out, wrap the implementation, not the call sites. A ConsentAwareAnalytics decorator that drops events when consent is off keeps the rule in one class. Crash reporting is different. setCrashlyticsCollectionEnabled can be called at runtime, but the Firebase docs say the override applies from the next launch, so a user who opts out mid-session is still reporting until the app restarts. Say that in your consent screen.

A debug build should not talk to production. I give the debug variant a LoggingAnalytics that prints to the console. It's another implementation of the same interface, which is the quiet argument for having the interface at all.

Wrapping up

Treat telemetry as a contract you own and a set of sensors you rent. The event names, the parameter keys, and the rule for what counts as a non-fatal live in commonMain, in code your compiler can check. The SDKs sit underneath, one per platform, and nobody outside the platform layer should know which ones.

I would still start with the interface even if the app only ships on one platform today. Adding iOS later then costs one Swift file instead of an audit of every event.

Same channel names, whatever the sensor. 🏁

The KMP Bits app is available on App Store and Google Play — built entirely with KMP.

Testing on production without polluting your data (and the day my tests voted 8 times)

Tue, 06 Oct 2026 13:36:20 +0000

Every release of Cá Viên Chiên ends with the same step: walk every changed flow on production, in Chromium and WebKit, at phone and desktop sizes, in both languages. Co-op rooms run on the real room server, share codes come from the real API, rewards are written to the real database.

That's a lot of fake players. Early on they all showed up in Google Analytics and in my own player count, so I wrote down one rule:

Test traffic never goes to Google Analytics. Our own API and database are used for real, with a test tag, and the tagged data is deleted when the tests are done.

Here is how that works on Cloudflare Pages + D1, and where it broke.

1. Nothing reaches Google Analytics

Every Playwright context goes through one helper before any page opens:

export async function guardContext(context, { presence = 'tag' } = {}) {
  // GA4's own opt-out flag, so gtag sends nothing even where its script loads
  await context.addInitScript({ content: `window['ga-disable-${GA_ID}'] = true;` });
  // Silence: the game's Web Audio graph runs into a gain of 0
  await context.addInitScript({ content: MUTE_INIT });
  // Drop analytics and ad hosts before the request leaves the browser
  for (const pattern of BLOCKED) await context.route(pattern, (r) => r.abort('blockedbyclient'));
  // Our own player count goes through, tagged as a test browser
  if (presence === 'tag') {
    await context.route('**/api/presence**', (r) =>
      r.continue({ headers: { ...r.request().headers(), 'x-cvc-test': '1' } }));
  }
}

BLOCKED covers Tag Manager, google-analytics.com, analytics.google.com, DoubleClick and AdSense. A local astro build loads GA4 too, so the guard applies to localhost as well.

There is a test for the guard itself: it scans every script in scripts/ that opens the site and fails if one doesn't import guardContext.

Chrome DevTools tabs driven over MCP can't block requests, so they get the same thing as an init script: the GA opt-out flag, the mute, and a fetch wrapper that adds the header.

2. The real API, with a tag

I don't fake our own endpoints. A faked /api/presence means no play record, which means no share code, which means the referral reward flow can't be tested at all. I found that out the hard way, by skipping the reward test on production once.

So the server stores test browsers like anyone else, with a flag:

// functions/api/presence.ts
const test = request.headers.get('X-CVC-Test') === '1' ? 1 : null;
await db.prepare(
  'INSERT OR IGNORE INTO installs (id, …, test) VALUES (?, …, ?)'
).bind(id, …, test).run();

The statistics page and pnpm stats skip installs.test = 1. Everything that hangs off an install (play days, first-session steps, replays, share codes, referral rewards, poster events) can be traced back to a tagged record.

3. Delete it when you're done

After every run, local or production:

node scripts/clean-test-data.mjs --remote        # delete
node scripts/clean-test-data.mjs --remote --dry  # count only: must be 0 everywhere

The script selects by the tag only, deletes dependents first, then the records, all in one call, then counts again and exits non-zero if anything is left:

const T = 'SELECT id FROM installs WHERE test = 1';
const TABLES = [
  ['referral_rewards', `newcomer_install_id IN (${T}) OR code IN (SELECT code FROM share_codes WHERE install_id IN (${T}))`],
  ['share_codes',   `install_id IN (${T})`],
  ['replays',       `install_id IN (${T})`],
  ['install_steps', `install_id IN (${T})`],
  ['poster_events', `install_id IN (${T})`],
  ['install_days',  `install_id IN (${T})`],
  ['installs',      'test = 1'],
];
run(TABLES.map(([t, w]) => `DELETE FROM ${t} WHERE ${w};`).join(' '));

The release checklist has test-rules before the deploy and test-cleanup after it. The deploy script refuses to run until the before items are answered, and the after items must pass before the release record is committed.

After the 1.37.0 release walk it deleted 129 test installs and everything attached to them. A real player's row is never selected.

4. The table that had no tag

Then I tested the new rating stars.

The game page has a "rate this game" card. My check opened it, hovered, and voted 4 stars, at two widths, in two languages, in two engines. Eight votes. Locally that was fine. On production, the log told the story on its own:

4 stars saved | 4.42/5 · 57 player ratings → 4.41/5 · 58 player ratings
…
4 stars saved | 4.38/5 · 64 player ratings → 4.37/5 · 65 player ratings

The ratings table has a voter id, a score, a hashed IP and timestamps, but no install id and no test flag. My cleanup script had no way to find these rows, and every vote moved the public average shown on every page and in the structured data.

Cleaning it up carefully:

List the newest rows, read-only. Eight rows from the same IP hash, alternating vi / en, all 4 stars, inside a three-minute window, matching the four Chromium and four WebKit runs exactly. The vote just before them came from a different address and stayed.

Count before deleting, with exactly the conditions the delete would use:

SELECT COUNT(*) FROM ratings
WHERE ip_hash LIKE 'a2c680bee7%' AND score = 4
  AND created_at BETWEEN strftime('%s','2026-10-03 13:50:00')*1000
                     AND strftime('%s','2026-10-03 13:53:30')*1000;
-- 8

Run the delete with the same WHERE: changes: 8.
Check the result: back to 57 votes and 4.42. The public summary is cached at the edge for 5 minutes, so the API caught up a few minutes later.

Then I made sure it can't happen the same way twice:

The rating check now stubs the POST when it runs on production and reads the live summary for its assertions. The real vote is tested only on the local stack.
The testing rules say it in one line: a test never votes on production, because a rating can't be tagged or found afterwards.
The script was run once more against production with the stub: 24 / 24 checks, still 57 votes.

What I'd tell myself a month ago

Block analytics in the browser, not in a dashboard filter. GA4's internal-traffic filters only apply from the day you turn them on.
Tag at the source. One request header, one column, and every derived row can be traced back to it.
Make cleanup a script with a count, not a habit. Exit non-zero if anything is left.
List every table a test can write to. Any table that can't be traced back to a tagged record needs its writes stubbed on production.
Count before you delete on production, with exactly the WHERE you're going to use.

The game is free in the browser at cavienchien.net.

Unstructured Data Analytics Tools Unlock Hidden Business Insights

Wed, 16 Sep 2026 10:30:31 +0000

Introduction

Businesses generate enormous amounts of information outside traditional databases. Customer emails, PDFs, social media conversations, images, videos, call recordings, documents, reviews, and machine-generated content can all contain valuable information, yet much of it cannot be analyzed easily using conventional reporting systems.

This is where unstructured data analytics tools become increasingly important. Instead of treating documents, text, images, and other non-tabular information as isolated files, modern analytics technologies can process these sources and turn them into useful business intelligence.

The growing interest in unstructured data analytics tools reflects a broader change in how organizations approach data. Companies are no longer relying only on structured databases for decision-making. They are looking for ways to combine structured and unstructured information to understand customers, operations, risks, and market trends more completely.

Understanding Unstructured Data

Structured data typically follows a predefined format, such as rows and columns in a relational database. Unstructured data does not follow the same predictable structure. It can include emails, contracts, presentations, photographs, videos, audio recordings, support tickets, web content, and social media posts.

The challenge is not simply storing these files. The real challenge is extracting useful meaning from them.

Modern unstructured data analytics tools use technologies such as natural language processing, machine learning, artificial intelligence, search, text mining, and computer vision to identify information within different formats. These capabilities can help organizations find relationships and patterns that would otherwise remain hidden.

For example, a retailer could analyze customer reviews and support conversations to identify recurring complaints. A financial organization could examine documents and communications to identify potential compliance concerns. A manufacturer could combine equipment records, maintenance documents, and sensor information to improve operational analysis.

How Unstructured Data Analytics Tools Create Business Value

The value of unstructured data analytics tools comes from their ability to convert difficult-to-use information into actionable insights.

Consider a company receiving thousands of customer messages every month. Reading every message manually is slow and inconsistent. An analytics platform can process the text, identify recurring subjects, classify sentiment, and reveal common issues.

The same principle applies to documents. Instead of searching through thousands of PDFs individually, unstructured data analytics tools can extract relevant fields, categorize documents, identify keywords, and make information easier to retrieve.

This creates a connection between raw information and business decisions. Analysts can spend less time locating information and more time interpreting what it means.

The Role of AI and Machine Learning

Artificial intelligence has significantly expanded the capabilities of unstructured data analytics tools. Traditional keyword searches can locate specific terms, but AI-based systems can understand relationships, context, classifications, and patterns across large collections of information.

Natural language processing can help interpret written content, while machine learning can identify recurring patterns. Computer vision can analyze visual information, and speech-processing technologies can convert conversations into searchable text.

Generative AI is also influencing this area. Once unstructured information has been properly ingested, cleaned, classified, and enriched with useful metadata, AI systems can use it for summarization, question answering, retrieval, and knowledge discovery.

However, AI does not eliminate the need for sound data management. Poor-quality source information can still produce unreliable results. Effective unstructured data analytics tools therefore need to work as part of a broader data pipeline rather than operate as isolated applications.

Connecting Different Data Sources

One major advantage of unstructured data analytics tools is their ability to bring information from multiple sources into an analytical workflow.

An enterprise might have customer information in a CRM platform, transaction records in databases, contracts stored as PDFs, conversations in communication platforms, and product feedback across websites and social networks. Looking at each source independently creates information silos.

Data integration can help bring these sources together. Once information is accessible through a common analytical environment, teams can compare structured records with unstructured content and develop a more complete understanding of a business problem.

For example, transaction data might show that sales declined in a particular region. Customer feedback could explain why. Combining both sources gives decision-makers context that a traditional sales report alone may not provide.

Choosing the Right Analytics Approach

Not every organization needs the same capabilities from unstructured data analytics tools. The right choice depends on the type of information being analyzed, data volume, technical requirements, security expectations, and business objectives.

A company primarily working with text may prioritize natural language processing and semantic search. An organization handling large document collections may need document extraction, classification, indexing, and metadata management. Businesses processing multimedia information may require image, video, or audio analysis.

Scalability is another important consideration. A tool that works well for a small collection of documents may not perform efficiently when data volumes increase significantly. Integration capabilities also matter because analytics rarely happens in isolation from existing databases, cloud platforms, business applications, and data pipelines.

Security and governance should be evaluated from the beginning. Sensitive documents and communications may contain confidential business information or personally identifiable information. Strong access controls, data protection, auditing, and appropriate retention policies are therefore essential considerations when evaluating unstructured data analytics tools.

Preparing Data for Reliable Analysis

The quality of analytical results depends heavily on the quality of the underlying information. Simply placing thousands of documents into an analytics platform does not automatically make them useful.

Organizations should consider how data is collected, classified, cleaned, enriched, indexed, and governed. Duplicate files, incomplete records, outdated documents, inconsistent metadata, and irrelevant content can reduce analytical accuracy.

Effective unstructured data analytics tools should therefore support a broader workflow that prepares information before analysis. This preparation can include extracting text from documents, identifying entities, assigning metadata, removing unnecessary content, and creating searchable representations.

Data quality becomes especially important when unstructured information is used for artificial intelligence applications. Reliable inputs provide a stronger foundation for analytics, machine learning, retrieval systems, and AI-generated outputs.

Moving Toward More Complete Business Intelligence

The growing adoption of unstructured data analytics tools represents a shift from traditional reporting toward broader information intelligence. Businesses are beginning to recognize that valuable insights are not limited to structured tables and predefined dashboards.

Emails can reveal customer concerns. Documents can contain contractual information. Reviews can highlight product weaknesses. Images and videos can provide operational evidence. Conversations can reveal changing customer expectations.

When these sources are analyzed alongside structured business data, organizations can develop a richer understanding of what is happening and why.

The future of enterprise analytics will increasingly depend on the ability to work across different data formats. Unstructured data analytics tools can help close the gap between information that is easy to query and information that contains valuable but difficult-to-access context.

Conclusion

Unstructured information is no longer simply an untapped collection of files. With the right technology, it can become an important source of business intelligence.

Modern unstructured data analytics tools help organizations process text, documents, images, audio, video, and other complex information while connecting these sources to broader analytical workflows. Their effectiveness depends not only on advanced AI capabilities but also on data quality, integration, governance, security, and a clear business objective.

Organizations that build a thoughtful approach to unstructured information can uncover insights that conventional analytics may overlook. As data volumes continue to grow and AI becomes more deeply integrated into enterprise workflows, unstructured data analytics tools will play an increasingly important role in turning hidden information into practical business knowledge.

Your AI Visibility Score May Be Wrong: A Reproducible Testing Protocol

Fri, 11 Sep 2026 20:10:27 +0000

By Jarno Saarimies, Founder of AEOvara. This is Part 3 of the series How to Build a Repeatable AI Search Visibility Benchmark.

Ask ChatGPT the same commercial question twice and you may get two different shortlists. Change “best” to “most reliable,” and the shortlist may change again. Run the prompt in a continuing conversation, in another country, or after a model update, and you may no longer be measuring the same system.

That creates an awkward problem for AI visibility reporting: a dashboard can show a precise score even when the experiment behind it is not precise.

This does not make AI visibility measurement useless. It means the score must be treated as an estimate produced by a documented test—not as an objective ranking retrieved from a fixed index.

In Parts 1 and 2 of this series, I explained how to build a prompt corpus and track mentions, citations, competitors, and answer quality. This article addresses the harder question:

When is a change in AI visibility evidence, and when is it only measurement noise?

The answer requires more than repeating prompts. You need to control the test environment, preserve the raw evidence, quantify uncertainty, and separate effects that dashboards often collapse into one number.

First, identify what actually changed

Suppose your mention rate rises from 30% to 40%. At least three different things could have produced that result.

1. The brand changed

You published new evidence, earned independent coverage, corrected an entity description, improved a relevant page, or became more widely discussed. This is the effect an AEO or GEO programme is trying to measure.

2. The engine changed

The provider released a new model snapshot, changed retrieval behaviour, refreshed an index, altered citation rules, or modified the product. OpenAI explicitly states that model outputs are variable and that prompting behaviour can change between model snapshots. For API applications, it recommends pinned model versions and evals when consistency matters.

Consumer AI products rarely give researchers complete control over those variables. A visible product name such as “ChatGPT” is not a permanent experimental condition.

3. The sample changed

The wording, session history, location, language, login state, retrieval mode, time, or number of repetitions changed. Even if the website and model stayed untouched, the measured score could move.

If your log cannot distinguish these explanations, it cannot support a causal claim such as “our optimization increased AI visibility by 10%.” It can only say that the observed answers changed.

That distinction sounds cautious. It is also what makes the result credible.

A prompt is not a keyword

Traditional rank tracking usually observes a defined query, location, device, and search engine. AI prompts carry more semantic degrees of freedom.

Consider these questions:

What are the best technical SEO consultancies for a Finnish SME?
Which technical SEO consultancy is most reliable for a small Finnish company?
Who can help a Finnish business become visible in AI-generated answers?
Recommend an affordable Finnish specialist in SEO and AI search optimization.

They occupy the same commercial neighbourhood, but they are not interchangeable samples. “Best,” “reliable,” “affordable,” and “AI search optimization” introduce different selection criteria.

A 2026 controlled study by Jan Ehrlinspiel, Malte Landwehr, and Tomek Rudzki examined 37,804 responses across five AI answer engines. It found that prompt format and archetype can shift visibility baselines, with the clearest sensitivity appearing in unbranded, middle-funnel commercial prompts. The authors are affiliated with Peec AI, so that commercial relationship should be disclosed, but the methodological lesson is useful: one wording cannot represent an entire buyer intent.

Freezing a prompt list is therefore necessary, but not sufficient. A frozen list gives you repeatability for those exact prompts. It does not prove that the list represents the full market.

Use prompt families, not a bag of convenient questions

A stronger benchmark separates two layers:

Core prompts remain unchanged so trends can be compared over time.
Prompt variants test whether the result survives realistic changes in wording.

For each buyer intent, write one core prompt and two or three variants before checking which version favours your brand. This prevents an easy form of unconscious cherry-picking: keeping the wording that produces the most flattering result.

Buyer intent	Core prompt	Controlled variants
Category discovery	What are the best AEO agencies in Finland?	most reliable; established; suitable for SMEs
Problem solving	How can a Finnish SME improve visibility in AI answers?	get cited by ChatGPT; appear in AI search; improve generative search visibility
Supplier selection	Who should I hire for an AI visibility audit in Finland?	independent specialist; consultancy; local expert

Do not average branded questions such as “What is AEOvara?” into the same score as unbranded discovery questions. A branded prompt measures recognition and description accuracy. An unbranded prompt measures discovery. Combining them can make a weak discovery result look healthy.

Record the test environment like an experiment

Every observation should include enough metadata for another person to understand what was tested:

exact prompt text;
platform and visible product mode;
model identifier, when exposed;
web search or grounding status, when exposed;
date, time, language, and country;
signed-in or signed-out state;
clean session or continuing conversation;
personalization or memory state, when known;
repetition number;
full answer and cited URLs;
scorer name or scoring-rule version.

“ChatGPT, September” is not adequate provenance. Neither is a cropped screenshot that hides the prompt, date, citations, and product mode.

API-based monitoring improves control, but it creates a different test. An API model with a pinned snapshot and explicit search configuration is not necessarily equivalent to the consumer interface used by customers. Report API observations as API observations. Do not quietly label them “what users see in ChatGPT.”

Measure a rate—and show its uncertainty

If a brand appears in 3 of 5 runs, the observed mention rate is 60%. That does not mean the true probability of a mention is known to be 60%.

With only five binary observations, a 95% Wilson confidence interval is approximately 23% to 88%. The interval is wide because the sample is small.

If the brand appears in 30 of 50 comparable runs, the observed rate is still 60%, but the corresponding interval narrows to approximately 46% to 72%. More observations have not changed the headline percentage; they have changed how much confidence we should place in it.

For a binary mention metric:

mention rate = mentions / comparable runs

Report the numerator and denominator—not just the percentage:

ChatGPT web search: 12/20 mentions, 60%
95% Wilson interval: approximately 39%–78%

The interval is not decoration. It helps prevent claims that the evidence cannot support.

If period A is 6/20 and period B is 8/20, the dashboard has moved from 30% to 40%. But with samples that small, the difference may be ordinary variation. Call it an observed increase, not a confirmed improvement.

Do not use one noise budget for every metric

Mention, citation, prominence, sentiment, and factual accuracy behave differently.

Mention is binary and relatively easy to score.
Citation requires a link or source reference and should be stored at URL level.
Prominence depends on an explicit rule: first named, top three, recommended, or merely included.
Sentiment is a classification judgement and is usually noisier.
Accuracy must be checked against a dated source of truth.

A 2026 production-data paper on GEO measurement reported that sentiment was 6.7 times noisier than mention in its dataset. That is one vendor’s observational result, not a universal constant, but it illustrates why a single blended “AI visibility score” can hide more than it reveals.

Publish the components separately. A brand can have a rising mention rate while its citation rate falls or its description becomes inaccurate. Those are materially different outcomes.

Establish a noise floor before claiming a win

Before changing the site, run the unchanged benchmark over several measurement windows. This creates a baseline for natural movement.

Then document the intervention:

page or entity changed;
exact publication time;
URLs affected;
intended prompt family;
no other known campaign, migration, or major PR event;
first date the changed page was observed or cited.

Continue measuring with the same core prompts and conditions. Compare post-change movement with pre-change variation.

This is still not a perfect causal experiment. AI engines can update during the same period, and third-party sources can change independently. But it is much stronger than editing ten pages and attributing the next dashboard increase to whichever tactic sounds most impressive.

Evidence	Defensible wording
One answer changed	“The brand appeared in this observation.”
Repeated rate increased	“Observed mention frequency increased in this prompt set.”
Increase exceeds baseline variation	“The change is larger than the noise previously observed in this test.”
Controlled intervention with comparison group	“The intervention is a plausible cause of the measured difference.”
Repeated controlled result across engines and periods	“The evidence supports a robust effect under the tested conditions.”

Avoid jumping from the first row to the last.

Build a holdout set to catch overfitting

If you optimize pages against the exact prompts used for reporting, you may improve performance on the test without improving broader buyer discovery.

Reserve 20–30% of your prompt families as a holdout set. Do not use those prompts to decide what to write or edit. Run them only at defined validation points.

If the core tracking prompts improve but the holdout prompts do not, you may have optimized to the benchmark rather than the market. This is the AI-search equivalent of teaching to the test.

The holdout set should remain commercially relevant. Random prompts do not create scientific rigour; they only create irrelevant data.

Publish the method, including its limitations

E-E-A-T is not a numeric score that can be added with an author box or a block of schema. For readers—and for systems trying to evaluate a source—trust is easier to establish when claims have visible provenance.

A credible public benchmark should state:

who ran the test;
what was measured;
the exact period and platforms;
how prompts were selected;
how many observations were collected;
how answers were scored;
whether the evaluator had a commercial interest;
what changed since the previous version;
what the data cannot prove.

That is the approach used in the continuously updated AEOvara AI Visibility Benchmark Suomi 2026: the platform-level results, prompt scope, cadence, and limitations are part of the evidence, not hidden behind a proprietary score.

Publishing an unfavourable or inconclusive result can strengthen the work. A benchmark that only produces success stories looks like marketing. A benchmark that preserves negative findings begins to look like a useful dataset.

A minimum viable reproducibility checklist

Before publishing the next percentage, ask:

Are branded and unbranded prompts reported separately?
Were prompts written before seeing which ones favoured the brand?
Are the exact wording and realistic variants preserved?
Were runs made in clean, comparable sessions?
Are platform, model, retrieval mode, location, and date recorded?
Does every percentage show its numerator and denominator?
Is uncertainty visible when the sample is small?
Are mentions, citations, prominence, sentiment, and accuracy separate?
Was a pre-change noise floor established?
Is there a holdout prompt set?
Are raw answers and cited URLs archived?
Are limitations and commercial relationships disclosed?

If several answers are “no,” the result may still be useful as an observation. It should not be presented as a stable market measurement.

The bottom line

AI visibility is measurable, but not as a single universal rank.

What you can measure is a defined brand’s behaviour across a documented sample of prompts, engines, configurations, places, and times. Repeat that protocol and you can build evidence. Hide those conditions behind a polished score and you create false precision.

The strongest AI-search report is not the one with the most decimal places. It is the one another practitioner could challenge, reproduce, and learn from.

That is also the kind of source worth citing.

FAQ

How many times should I run each AI-search prompt?

There is no universal number. Three to five repetitions can expose obvious variability and provide a directional baseline, but a small sample does not produce a precise probability. Report the raw count and an uncertainty interval, then increase repetitions for important or volatile prompt families.

Should I freeze my prompts or update them?

Do both in separate layers. Keep a stable core set for trend comparison, and maintain a versioned discovery set that reflects new buyer language, products, and competitors. Never silently replace old prompts and continue the same trend line.

Can I compare an API result with the consumer AI product?

Only with an explicit caveat. The API may use a different model snapshot, system configuration, search policy, location input, or citation interface. Treat it as a separate measurement surface unless equivalence has been demonstrated.

Is a higher mention rate proof that my content change worked?

No. It is evidence that the observed rate changed. A causal claim requires stronger controls: stable test conditions, a pre-change noise floor, documented timing, enough observations, and preferably a comparison or holdout group.

Does a citation mean the AI answer used my page correctly?

Not necessarily. Store and inspect the cited URL, the claim it appears to support, and whether the answer accurately represents the source. Citation presence and citation correctness are separate metrics.

Sources and further reading

OpenAI, API backwards compatibility and model variability.
Ehrlinspiel, Landwehr & Rudzki, Prompt Tracking Works, But Not as a One-Prompt Measurement System, 2026.
Blago, Generative Engine Optimization at Scale: Measuring Brand Visibility Across AI Search Engines, 2026. Treat the vendor-operated production dataset and its generalizability accordingly.
Aggarwal et al., GEO: Generative Engine Optimization, KDD 2024.

About the author: Jarno Saarimies is the founder of AEOvara, a Finnish consultancy focused on technical SEO, Answer Engine Optimization, Generative Engine Optimization, and reproducible AI-search visibility measurement. His work emphasizes documented methods, source verification, and claims that remain useful after the hype cycle moves on.

How to Detect Airdrop Farmers on Polymarket Leaderboards

Sat, 29 Aug 2026 21:49:23 +0000

A 90% win rate looks like proof of skill. On Polymarket it usually isn't. Of the 70,711 wallets currently showing a 90% or higher win rate, about 61%, or 43,179 of them, are airdrop farmers. They never took a real position. They bought outcomes that were already all but settled, collected a few cents, and repeated it thousands of times to farm volume and a spotless record.

If you pick wallets to follow off a raw leaderboard, the math says you are probably copying one of them. Here is how to tell a farmer apart from a real trader.

How can I detect airdrop farmers on Polymarket leaderboards?

An airdrop farmer is a wallet with an average buy price above 95 cents. That single number is the fingerprint. Real traders take uncertain positions at a range of prices, so their average entry lands somewhere in the middle. A farmer's average sits near the top of the book, because the whole strategy is buying near-certain outcomes for the last sliver of profit. Sort a leaderboard by win rate, check the average entry price of the wallets at the top, and the farmers separate themselves.

OrcaLayer does this automatically. Every ranking is farmer-filtered by default, so the wallets you see have taken real risk. The exact rules are on the Farmer Filter page and in the full methodology.

What an airdrop farmer actually does

The play is simple and low risk. Find a market that will clearly resolve one way. Buy the winning side for almost its full value. Wait for settlement.

Say a market is going to resolve Yes. The farmer buys Yes at 96 cents. It settles at 1 dollar. That is 4 cents of profit on the dollar, near guaranteed. Do it once and it is pocket change. Do it across thousands of markets and you farm two things at the same time: a near perfect win rate, and the trading volume that qualifies for airdrop and rewards programs. The skill involved is close to zero.

This is why raw leaderboards mislead. Sort any unfiltered Polymarket ranking by win rate and the top is a wall of 95 to 100 percent records. It reads like a roster of geniuses to copy. Most of them are farmers, and a 96 cent entry is not something you can profitably copy anyway.

The three signals, in detail

Farmers are one of three kinds of leaderboard noise. OrcaLayer separates each one on its own, so any of them can be filtered independently.

Farmers. Average buy price above 95 cents. You do not accumulate an average that high by taking genuine, uncertain positions. Flagged and excluded from Smart Money.

Bots. More than 500,000 trades and an average trade size under 20 dollars. That is the signature of an automated market-making or micro-arbitrage program, not a person taking real positions.

Router contracts. Polymarket's own protocol contracts, the CTF and NegRisk exchange routers, sit on both sides of ordinary trades. Left in, a router can look like a single hyper-active insider wallet. Excluded platform-wide.

Across every trader OrcaLayer has indexed, about 114,000 are farmers, roughly 1 in 12, and they cluster exactly where they do the most damage: at the top of an unfiltered win-rate ranking.

Raw leaderboard vs farmer-filtered

	Raw Polymarket leaderboard	OrcaLayer, farmer-filtered
Top sorted by win rate	Wall of 95 to 100 percent records	Wallets that took real positions
Farmers	Dominate the top	Flagged and removed
Bots and routers	Counted as traders	Detected and excluded
Can you copy the entries	Rarely, most sit near 1 dollar	Yes, real entry prices

Once the farmers come out, the "flawless" leaderboard mostly disappears. What is left is the smaller, more honest set OrcaLayer calls Smart Money: a wallet with a 55 percent or higher market win rate, positive total profit, and no farmer flag. Just under 198,000 wallets qualify.

How to check a wallet yourself

If you want to vet a wallet by hand:

Look at its average entry price. Above 95 cents is a farmer tell.
Look at trade count and average size. Hundreds of thousands of trades at a few dollars each is a bot.
Ask whether the wins came from real, uncertain positions or from near-settled ones.

Or open the OrcaLayer leaderboard, which applies all three checks by default and shows you which wallets took real positions. The full data story behind the filter is in the 470M-trade farmer analysis.

Frequently asked questions

How can I detect airdrop farmers on Polymarket leaderboards? Check a wallet's average buy price. Farmers sit above 95 cents, because they buy near-settled outcomes for a few cents of guaranteed profit. OrcaLayer flags every such wallet automatically and removes it from the rankings.

What percentage of high win-rate wallets are farmers? Of the 70,711 Polymarket wallets with a 90 percent or higher win rate, about 61 percent, or 43,179, are farmers.

Why do airdrop farmers have such high win rates? Because they only buy outcomes that are already almost certain, often at 96 cents or more. It produces a near perfect record with almost no risk and almost no skill.

How does OrcaLayer remove farmers? By three independent signals: an average buy price above 95 cents for farmers, over 500,000 trades with an average size under 20 dollars for bots, and Polymarket's own router contracts, which are excluded platform-wide. The thresholds are published in the methodology.

What is left after farmers are removed? Just under 198,000 wallets that OrcaLayer classifies as Smart Money: a 55 percent or higher market win rate, positive total profit, and no farmer flag.

Can I copy a farmer's trades to make money? No. Their edge is buying at 96 cents or more on near-settled markets, which leaves almost nothing for a follower and disappears once the market resolves.

What average entry price signals a real Polymarket trader? A genuine trader's average buy price tends to land in the middle of the book, because real positions are taken while the outcome is still uncertain. An average above 95 cents is the farmer tell, not the mark of a skilled trader.

Originally published on orcalayer.com.

Data Analytics Services: Transform Raw Data into Actionable Business Insights

Wed, 29 Jul 2026 14:21:27 +0000

Turn data into a competitive advantage with end-to-end data analytics services. From data strategy and integration to AI-powered analytics, reporting, visualization, and DataOps, organizations can uncover actionable insights that improve decision-making, optimize operations, and accelerate business growth. This infographic highlights the core capabilities, business benefits, and analytics workflow that help enterprises build a trusted, data-driven foundation for long-term success.

Your API has visitors GA4 will never see

Wed, 24 Jun 2026 09:10:54 +0000

Are you building an API for AI agents? If so, you might be flying blind.

Google Analytics 4 (GA4) is great for tracking human users with browsers, but it is completely blind to AI agents, bots, and server-to-server API calls.

When an AI agent (like OpenClaw or a custom script) calls your MCP endpoint or REST API, it does not execute JavaScript. There is no gtag.js running. You see nothing in GA4.

You are effectively serving a silent, invisible army of customers that you cannot track, understand, or optimize for.

The Problem: GA4 is designed for humans, not bots

GA4 relies on client-side JavaScript to send tracking data to Google. This works well for websites.

It does not work for:

API calls from AI agents.
Requests from curl, Python, or Node.js scripts.
MCP (Streamable HTTP) traffic.
Webhook calls.

Your most important customers (the agents and bots that pay you) are invisible.

The Solution: Track at the server level

Instead of relying on GA4, you can track everything from your own server. Every incoming request has headers and metadata that you can log and analyze.

You can build a simple logging middleware that records:

Endpoint path.
User-Agent string.
IP address.
Response time.
Status code.
API key or auth identifier.

Then, you can parse the logs to understand who is calling your API and how they are using it.

What you can learn

By analyzing server logs, you can answer questions that GA4 never can:

How many AI agents are using your API?
What are the most popular endpoints?
Which user-agents are making the most requests?
Are there any abusive or unusual patterns?
Where are your agent users coming from? (IP geolocation)

A practical example

I built a project called AgentShare (agentshare.dev), a platform that provides structured price data for AI agents via REST and MCP.

Instead of relying on GA4, I built a log analysis system on the server. I now get daily reports on:

The number of agent requests.
The top endpoints.
The most active user-agents.
Anomalies and error rates.

This data helps me make product decisions and understand my real customers.

I wrote about this journey in detail here: "Your API has visitors GA4 will never see".

Try it yourself

If you are building an API for AI agents, do yourself a favor: stop relying on GA4 and start tracking at the server level.

Add a logging middleware.
Store logs in a database or a file.
Write a simple script to analyze the logs.
Set up a daily report.

You will be surprised by what you discover.

Have you ever tracked AI agent traffic on your API? What did you learn?

Causality Engine

Sun, 21 Jun 2026 03:58:15 +0000

Causality Engine is a marketing attribution platform that uses causal inference, not correlation, to show e-commerce brands which marketing channels actually drive sales.

Traditional tools like Google Analytics credit the last click. If a customer saw an Instagram ad, opened an email, then Googled your brand name, Google gets 100% of the credit. The ad and the email get zero. This causes marketers to systematically overspend on bottom-funnel channels and underfund the ones that create demand.

Causality Engine fixes this. Upload a Google Analytics CSV and get a full causal attribution analysis in minutes. No pixels, no SDKs, no developer needed. The platform reveals 15-25% of revenue that traditional attribution structurally cannot see, and quantifies it as an exact euro amount per channel.

Built for e-commerce brands doing €5K+ monthly revenue. All data is EU-hosted. GDPR-compliant from the ground up with right-to-erasure, data anonymisation, and fraud detection built in.

Pricing starts at €99 for a single analysis. Pro subscribers (€299/mo) get unlimited analyses, AI chat, and full historical lookback.

Get started now: https://causalityengine.ai

The Data Science Behind Marketing Attribution: Moving Beyond Client-Side Correlation

Sun, 21 Jun 2026 03:58:06 +0000

As browser privacy controls and ad-blockers tighten globally, developers and data engineers face a growing bottleneck: client-side event tracking is becoming increasingly unreliable.

The traditional way to measure marketing performance relies on third-party tracking scripts, front-end pixels, or heavy SDKs embedded into the browser. When a conversion occurs, the client-side script parses the current session source and credits it with the sale. This structure usually implements a "last-click" attribution framework.

The Engineering Flaw of Last-Click Data

From an architectural standpoint, last-click tracking reduces a multi-touchpoint user journey down to a single relational database entry.

Consider this standard pipeline sequence:

User interacts with a top-of-funnel ad via a social media platform.
User enters an email marketing loop and clicks a mid-funnel link.
User runs a quick direct brand search on Google to execute the transaction.

In a last-click data model, the brand search capturing the transaction gets 100% of the conversion credit. The discovery ad and email nurture nodes get zero. This structural blind spot causes a massive misallocation of budget toward bottom-funnel channels while starving the systems that generate baseline demand.

Solving Inaccuracies with Backend Causal Inference

The alternative to flawed client-side correlation is server-side causal inference. Instead of evaluating isolated browser events as they execute, the logic shifts entirely to the backend, analyzing complete historical data records.

By processing standardized exports (such as a standard Google Analytics CSV export), server-side algorithms can run independent multi-touchpoint analysis without client-side execution overhead.

Engineered platforms in this space, like Causality Engine, approach this mathematically rather than using arbitrary linear rules. By moving processing to a secure backend, it bypasses browser script blockers entirely. This architecture successfully surfaces 15% to 25% of hidden conversion revenue that standard tracking scripts fail to capture, outputting the exact value metrics per channel.

Architectural Benefits: Performance & Compliance

Shifting your analytics stack from front-end pixels to server-side file processing tackles two core infrastructure requirements:

Site Reliability Engineering: Eliminating external script execution on the frontend improves core web vitals and eliminates page latency.
Compliance by Design: Processing data purely via historical logs enables deterministic data privacy. Platforms can maintain fully EU-hosted environments with native data anonymization, strict right-to-erasure workflows, and integrated fraud detection layers without complicating front-end consent scripts.

How is your engineering team adapting data architectures to handle multi-touch attribution as browser cookie restrictions expand? Let's talk in the comments.

Why Token Analysis Isn't Enough Anymore

Fri, 12 Jun 2026 03:09:41 +0000

The Industry Is Looking at the Wrong Thing

For years, crypto security has revolved around a single assumption:

If we analyze a token thoroughly enough, we can understand its risk.

This assumption gave rise to an entire ecosystem of tools.

Liquidity checkers.

Contract scanners.

Holder analyzers.

Rug pull detectors.

Risk scores.

Audits.

Dashboards.

Alerts.

Every day, thousands of traders open these tools and ask the same question:

Is this token safe?

At first glance, it seems like a reasonable question.

A token is visible.

It has a contract.

It has holders.

It has liquidity.

It produces data.

Data can be analyzed.

Analysis can produce a score.

The score can be used to make decisions.

The logic appears sound.

The problem is that reality refuses to cooperate.

Despite years of increasingly sophisticated token analysis, the same scams continue to appear.

The same manipulation strategies continue to work.

The same outcomes continue to repeat.

The industry keeps getting better at analyzing tokens.

Yet it remains surprisingly ineffective at understanding the people behind them.

And that may be because we are analyzing the wrong entity.

A Strange Pattern

When we first started building NexusVeritas, our goal was not particularly ambitious.

We wanted to build a better risk engine.

Like everyone else, we looked at the usual signals:

Liquidity.

Holder concentration.

Funding sources.

Wallet activity.

Transaction flows.

The idea seemed straightforward.

Collect enough information about a token and eventually risk becomes measurable.

Then something unexpected happened.

The more cases we analyzed, the less important the tokens themselves seemed.

Different names.

Different branding.

Different communities.

Different narratives.

Different websites.

Different contracts.

Yet beneath the surface, certain behavioral patterns kept reappearing.

The same launch structures.

The same wallet behaviors.

The same funding routes.

The same distribution patterns.

The same operational mistakes.

Again and again.

At first it felt like coincidence.

Then it became difficult to ignore.

Eventually a different hypothesis emerged:

Perhaps the token wasn't the real subject of analysis.

Perhaps it was merely the artifact left behind by something else.

Tokens Are Disposable

One of the most misunderstood aspects of crypto is how cheap identity has become.

In traditional finance, creating a new legal entity requires paperwork, compliance, and significant effort.

In crypto, creating a new wallet takes seconds.

Creating a new token takes minutes.

Creating an entirely new project can take hours.

This changes the economics of deception.

If a token becomes associated with failure, an operator can abandon it.

If a wallet becomes known, it can be discarded.

If a community turns hostile, a new brand can emerge tomorrow.

The cost of replacing the visible layer is almost zero.

The industry understands this intellectually.

Yet most analytical systems still behave as if wallets and tokens are stable identities.

They are not.

They are disposable infrastructure.

The operator remains.

The Wallet Illusion

Many blockchain tools implicitly treat wallets as people.

This is understandable.

Wallet addresses are visible.

People are not.

So the wallet becomes the proxy for identity.

But this shortcut creates a dangerous illusion.

Imagine an operator launches ten tokens.

Each token uses a different wallet.

Each wallet receives funding through a different route.

Each launch occurs under a different name.

To a traditional analytics platform, these may appear to be ten unrelated events.

To the operator, it is Tuesday.

The blockchain has changed.

The behavior has not.

And behavior is where identity begins to emerge.

Behavior Leaves Fingerprints

Human beings are creatures of habit.

We develop patterns without realizing it.

We repeat decisions.

We optimize routines.

We recycle infrastructure.

We fall back on familiar processes.

Operators do the same thing.

Some consistently launch at similar times.

Some repeatedly use the same funding structures.

Some distribute supply in nearly identical ways.

Some follow recognizable liquidity patterns.

Some deploy entire networks of fresh wallets that behave almost identically across multiple launches.

Individually, these signals may seem insignificant.

Together, they become something far more powerful.

A behavioral fingerprint.

Not a name.

Not a legal identity.

Not a social media account.

A behavioral identity.

A signature created by repeated decisions.

And unlike wallets, behavioral signatures are surprisingly difficult to replace.

Changing a wallet is easy.

Changing operational habits is much harder.

The Shift from Token Intelligence to Operator Intelligence

This realization changes the question entirely.

For years, the industry has asked:

Is this token dangerous?

But tokens do not make decisions.

Tokens do not coordinate launches.

Tokens do not move funds.

Tokens do not execute exits.

People do.

Operators do.

The more interesting question becomes:

Is this operator dangerous?

This is a fundamentally different problem.

Instead of evaluating assets, we begin evaluating behavior.

Instead of scoring contracts, we begin identifying patterns.

Instead of tracking tokens, we begin tracking operators.

The subject of analysis changes.

And with it, the entire intelligence model changes.

Why Existing Tools Reach a Ceiling

Most existing risk tools are extremely useful.

But they share a common limitation.

They focus on the present.

What does this token look like today?

What does this wallet look like today?

What does this contract look like today?

The problem is that risk often originates in the past.

An operator may have launched twenty previous projects.

They may have participated in multiple failed ecosystems.

They may have recycled infrastructure across dozens of deployments.

They may have developed highly recognizable operational patterns.

None of that information exists within a single token.

It only becomes visible when behavior is analyzed across time.

The challenge is no longer blockchain analytics.

The challenge becomes attribution.

Attribution Is the Next Frontier

The word "attribution" is common in cybersecurity.

Investigators rarely begin by asking:

What happened?

Instead, they ask:

Who has done something like this before?

The same principle applies on-chain.

As the ecosystem matures, the most valuable intelligence will not come from analyzing isolated events.

It will come from connecting events together.

Identifying recurring operators.

Discovering behavioral clusters.

Recognizing infrastructure reuse.

Building operational histories.

Creating memory where none previously existed.

This is where the future of blockchain intelligence is heading.

Not toward bigger dashboards.

Not toward more complicated risk scores.

Toward attribution.

Building Memory

Perhaps the biggest weakness of today's crypto ecosystem is collective amnesia.

Every day, thousands of new tokens appear.

Every day, thousands disappear.

The market forgets quickly.

Operators understand this.

Many depend on it.

What happens when the market starts remembering?

What happens when behavior becomes searchable?

What happens when launch history becomes reputation?

What happens when every new project can be compared against years of operational patterns?

The economics begin to change.

The cost of abandoning a wallet remains low.

The cost of abandoning a behavioral identity becomes much higher.

That is where things become interesting.

The Next Decade

The first generation of crypto intelligence focused on assets.

The second generation focused on transactions.

The next generation will focus on operators.

Not because tokens are unimportant.

But because tokens are temporary.

Operators persist.

Infrastructure evolves.

Wallets rotate.

Brands disappear.

Behavior remains.

The question that defined the last cycle was:

What is this token?

The question that may define the next cycle is:

Who is behind it?

That shift may sound subtle.

In reality, it changes everything.

Because wallets change.

Operators adapt.

Behavior leaves fingerprints.

Through the Looking Glass: Why Your Server Logs Are a Playground for Cyber-Detectives

Thu, 11 Jun 2026 13:54:28 +0000

When you deploy a custom analytics package or any traffic-monitoring tool, your expectations are usually modest: a few hits from friends, maybe your mom, or an occasional lost translator bot. But after the server runs for a couple of days, the reality often turns out to be significantly more complex.

Recently, while auditing the logs of my Laravel-based analytics package, I discovered that my project had become a focal point for researchers who don't just "scroll the feed," but dissect the internet down to its molecular level.

As a developer, it made me curious: what exactly are these "guests from the future" (like Firefox 140.0) looking for, and why are corporate entities like Palo Alto Networks suddenly keeping such a close eye on a domain that barely existed yesterday?

When "Grey" Traffic Becomes an Object of Study

The first thing that stands out in the logs isn't the usual bot noise, but Power Users. I’m talking about visitors coming via IPv6 tunnels, using Linux, and identifying as DuckDuckGo users. These are individuals who consciously avoid tracking and operate with tools that most of us consider "advanced" or "niche."

They behave like professional auditors:

Protocol Adherence: Checking robots.txt before crawling.

Jurisdictional Assessment: Analyzing Terms of Service within seconds (a classic professional trait: understand the jurisdiction before pulling the trigger).

Intentional Focus: Bypassing general content in favor of direct interaction with security tools (like DNS audits).

This is a vital signal for any engineer: if your software attracts this type of user, you've built something genuinely practical. Simultaneously, it serves as a high-stakes stress test for your entire stack.

DNS Detective: The "Karachi Police" Case

The situation becomes truly fascinating when your tool starts being used as a "proxy scanner" to probe other resources. For instance, I noticed requests hitting karachipolice.gov.pk via my tool. Using an independent auditor to probe a government domain is a perfect example of how borders vanish on the web.

What did the audit reveal, and what should you look for in your own projects?

DMARC: null. An absent protection policy is an open invitation for attackers to perform email spoofing.

SPF ~all. A "soft" lock that exists formally but fails to effectively block unauthorized senders.

IPv6 Facade. A site may correctly resolve via modern AAAA records, but still rely on an outdated, vulnerable mail infrastructure behind the scenes.

This case serves as a sharp reminder: domain security isn't about wall thickness; it's about the precision of a single DNS record. If you haven't audited your own domain's configuration in a while, it is high time to verify those settings — you can run a free DNS audit to ensure your records are as airtight as they need to be.

Corporate "Ghosts" from Palo Alto Networks

While the first group represents human researchers, Palo Alto Networks and their peers represent the world of automated global threat mapping. Once your service begins exhibiting behavior resembling a network scanner, it inevitably ends up on corporate radar.

For a developer, this is a critical turning point:

Your domain reputation is being built automatically.
If your service behaves "professionally" (Laravel 12, clean headers, valid configurations), algorithms flag you as a legitimate research node, which improves your trust rating across the "clean internet."

Final Thoughts: What Should We Learn?

Analytics is more than just traffic charts; it is a powerful tool for code hygiene and security. When you read your logs, you are reading the story of the web in real-time.

If you are interested in the technical implementation details of how I built this package without crashing production, or want to dive deeper into the security of HTTP headers (and why a single forgotten comma in your CSP can "kill" your site for Googlebot), check out these resources:

How I Built My Own Laravel Analytics Package (and Almost Didn't Crash Production) — Technical implementation details.

Your Digital Fortress: Why a Security Headers Audit is Essential — Why headers are the first thing every "pro" checks.

Take care of your HTTP headers, and don't forget to check your logs. They are always more interesting than Google Analytics.

Building a Digital Customs Checkpoint: My 7-Part Journey in Laravel Analytics & Bot Defense

Thu, 04 Jun 2026 09:00:00 +0000

Over the past year, developing laravel-visit-analytics has evolved from a simple experiment into a significant engineering challenge. When standard analytics tools failed to meet my requirements for GDPR/DSGVO compliance and data accuracy, I realized: if you want it done right, do it yourself.

This 7-part series chronicles my transition from naive trust in browser headers to building a system that detects botnets in real-time based on their unique "digital fingerprints."

Project Roadmap:

Phase 1: Architecture & Foundation

Chapter 1: Breaking Free from the Giants. Why I abandoned Google Analytics for a Privacy-First approach — How I Built My Own Laravel Analytics Package (and Almost Didn't Crash Production).
Chapter 2: Refactoring 2.0. Replacing heavy middleware with an elegant Chain of Responsibility and optimizing database performance — Refactoring Laravel Visit Analytics: The Path to Version 2.0.0.

Phase 2: The Logic of Suspicion

Chapter 3: The Lie Detector. Implementing a scoring system, Snowball Effect, and honeypots to filter out "junk" traffic — A Lie Detector for HTTP Requests: Analytics Through Time.
Chapter 4: Through the Looking Glass. How DNS auditing and IPv6 analysis helped uncover true traffic sources — Through the Looking Glass of Logs: Karachi Police, DuckDuckGo, and IPv6 Magic.
Chapter 5: Code with a Human Face. The story of how I almost banned my son's vintage Sony Ericsson and why I implemented a "mercy coefficient" — Human-Centric Bot Detection: Lessons from Sony Ericsson and Win98.

Phase 3: Advanced Defense

Chapter 6: Hunting Digital Chameleons (Part 1). Defeating botnets via Client Hints and implementing real-time anonymization in v2.4.0 — Hunting Digital Chameleons: How We Defeated Botnets in Laravel v2.4.0.
Chapter 7: Hunting Digital Chameleons (Part 2). Why session imitation is a bot's weak point and how I detect anomalies in session stability — Hunting Digital Chameleons: Why Session Imitation Is the Weakest Link for Modern Bots.

What’s Next?
The foundation is set. I am currently focusing on data integrity, but plans are already in motion to visualize these threat patterns directly in the Laravel Filament dashboard. Stay tuned!

From Google Analytics to Matomo: How We Migrated Our Web Tracking to Our Own Infrastructure

Mon, 01 Jun 2026 10:45:26 +0000

We replaced Google Analytics with Matomo, an open-source web analytics platform that we run on our own infrastructure in Switzerland. In this article, we describe why we made this move, how we implemented the migration technically, which Nine services we used, and what we gained and lost in the process.

Why We Replaced Google Analytics

Google Analytics is the default web tracking solution for many companies. We used it for years. Still, we had long been uncomfortable with the fact that all visitor data from our website was being transferred to Google servers in the US.

This is not merely a philosophical question. As a Swiss managed services provider that advocates data sovereignty and transparency to customers, it was difficult to explain why our own analytics data ended up with a US corporation. Specifically, these were the factors we weighed:

Data ownership: Visitor data from nine.ch, docs.nine.ch, Cockpit, and deplo.io was transferred to Google in the US, without us having any direct control over retention periods or usage.
Cookie consent requirement: GA4 sets tracking cookies, which requires explicit user consent. This meant a relevant share of visitors declined analytics, leaving our data incomplete.
GDPR compliance: The legal situation around GA4 and GDPR has been contested in the EU and Switzerland for years. Several data protection authorities have classified GA4 as non-compliant.
Consistency: We recommend that customers run their infrastructure in Switzerland. Our own analytics solution should meet that same standard.
The decision in favour of Matomo came quickly: open source, self-hostable, operable without cookies, actively developed, and with comparable functionality for our needs.

What We Track: Four Properties

We operate four digital properties for which we need analytics:

Property/ Technology

Website (nine.ch) / Hugo (Static Site)
docs.nine.ch / Docusaurus v3
Cockpit (Customer Portal) / Ruby on Rails
deplo.io (Deploio Landing Page) / Google Tag Manager (Matomo added additively)

Each property has its own dashboard in Matomo, and user permissions can be granted granularly per property.

The Technical Implementation

Server and Infrastructure

Matomo 5.10.0 runs on a virtual Nine Managed Server on our Swiss infrastructure. The following Nine services are used to run it:

Managed Server with Nginx and PHP-FPM (PHP 8.5.6)
Managed MySQL (version 8.0 on Ubuntu 24.04 LTS, support until May
2029)
Daily backups (included in the Managed Server offering)
Puppet for all server configuration and deployment
Nginx hardening via Puppet: sensitive Matomo directories (tmp/,
config/, lang/, misc/, vendor/) are blocked from external access, and
PHP execution is restricted to the root directory

The entire server configuration, including the Nginx rules, is managed via Puppet. This means no manual configuration on the server – everything is versioned and reproducible.

Matomo offers a cookieless operating mode that sets no tracking cookies. This has an important consequence: since no cookies are set, no visitor consent is required. The cookie banner on nine.ch no longer contains an analytics category, and data is complete regardless of whether a visitor accepts or declines cookies.

Analysis is based on anonymised data. The last two bytes of the IP address are removed before storage, making personal identification technically impossible. The data never leaves our servers.

The legal basis is Art. 6(1)(f) GDPR (legitimate interests).

Integration Across the Four Properties

nine.ch (Hugo): The Matomo tracking snippet is embedded directly in via the Hugo template. A hugo.IsProduction guard ensures that no tracking occurs on staging or local environments. At the same time, the GA4 initialisation and analytics category were removed from the cookie consent script. Existing GA cookies (_ga, _gid) are cleared on the first page load.

docs.nine.ch (Docusaurus v3): The GA4 preset was removed from docusaurus.config.ts. The Matomo snippet is embedded via Docusaurus’s headTags mechanism, also with a NODE_ENV === "production" guard. GA cookie cleanup is integrated in the same script.

Cockpit (Ruby on Rails): The snippet is embedded in the application layout (application.html.erb), with a Rails.env.production? guard and the correct CSP nonce to avoid violating the Content Security Policy header.

deplo.io: The Deploio landing page is maintained by our colleagues at Renuo. Renuo continues to use Google Analytics for their own reporting. They added the Matomo tag additively in GTM, so visitor data now flows into our Matomo instance as well.

Content Security Policy

Since Matomo runs on its own subdomain, the CSP headers of the website had to be updated. The Matomo subdomain was added to script-src, img-src, and connect-src. This covers loading matomo.js, the tracking pixel (fallback), and the XHR/Beacon requests to matomo.php.

Privacy Policy

The privacy policy on nine.ch was updated: the section on Google Analytics was replaced with a section on Matomo, explaining the cookieless operation, the Swiss data location, and the anonymisation of IP addresses.

What We Gained Compared to Google Analytics

Complete data: No sampling, no data thresholds (GA4 hides values
below 10 events), no gaps caused by consent refusals.
Unlimited data retention: GA4 defaults to 14 months, with a maximum
of 26. With Matomo, the decision is ours.
Individual visitor logs: Matomo allows viewing individual sessions,
which is not possible in GA4.
Data sovereignty: All data stays on our own infrastructure in
Switzerland.
No third party involved: Google had access to our visitor data. That
is no longer the case.
GDPR compliance without effort: No consent dialog for analytics, no
dependency on third-party rulings.

What We No Longer Have

Honesty matters here: there are features GA4 offers that Matomo does not have in its base version.

Search Console Integration (Keywords): GA4 could be connected to
Google Search Console, making organic keywords visible. This feature
is a paid add-on in Matomo. For us, it is the only relevant gap, and
one we plan to close with the plugin in the medium term.
Google Signals / Demographics: GA4 could collect demographic data
from logged-in Google users, something we will also add later via
plugin.
Predictive Metrics: GA4’s machine learning predictions require a data
volume that is not relevant for us.
BigQuery export: Not needed for our purposes.

Conclusion

The migration was technically manageable and worth the effort. We now have an analytics solution that aligns with our values: data on our own infrastructure, in Switzerland, without third parties. The cookieless operation is a bonus that makes our data more complete than before.

If you have similar requirements – data sovereignty, GDPR compliance, and complete data without consent friction – we recommend Matomo on a Managed Server as a straightforward and low-maintenance approach.

If you have questions about the implementation, feel free to reach out.

From GTM migration to missing UTM columns: getting ad attribution right as a solo founder

Mon, 18 May 2026 20:38:01 +0000

Last month I migrated XreplyAI from hardcoded gtag snippets to Google Tag Manager.

One container. All pixels managed in one place. No code deploys to add or change tags. I thought that was the hard part of getting ad attribution right.

It wasn't.

This morning I finished wiring Google Ads conversion tracking — trial_start firing server-side via the GA4 Measurement Protocol, conversion imported into Google Ads, bidding optimized for trials.

Then a new user signed up. And I had no idea where they came from.

Not because GA4 didn't know. GA4 knew — "google / cpc." But our users table has no UTM columns. So I can't:

Calculate LTV by acquisition channel
Know whether Google Ads or X Ads drove a signup
Filter subscribers by source when making budget decisions
The fix is obvious in hindsight: store utm_source, utm_medium, utm_campaign, utm_content, and gclid on the user record at signup. Capture them from the URL on landing, pass them to the backend at magic link / signup time, persist once, never overwrite on subsequent logins.

It's a 2-hour task. I opened a GitHub issue this morning.

The lesson: GTM solves "where do my tags live." UTM columns on users solve "where did this specific person come from." You need both. Most founders running paid traffic have neither.

Fix it before you spend another dollar on ads.

Building XreplyAI in public — an AI social media tool for solo founders. BYOK model, voice-matched content across 8 platforms. xreplyai.com

Full Sales Data Analysis: From Raw Data to Interactive Business Dashboard

Sun, 17 May 2026 08:03:49 +0000

Introduction

Anybody can be a data analyst,but what separates a good data analyst from a great one is what you can do and present.In this article i will be giving step by step guidelines from turning a raw data to an interactive business dashboards and giving insights.We will generate our sales data from Mockaroo,use Python to turn the JSON file to CSV,analyse with Sql and visualize with Power Bi.

1.Generating the sales data.

You will go to your browser and search Mockaroo.com.Once open,hit the generate data button and give AI a command to generate the data for you.You can select the number of rows that you want your data to have.Once its done,save the data as a json file.

a.Viewing the data

Once your data is generated and saved in your files in your machine,go to your Github account and add that file to your repo.

Once you open that file,hit the raw button and you will see something like this:

2.Importing using Python.

The work is not yet done.Copy the link from your raw data in github because we shall need it.Use the import requests and the url will be your link you copied from raw data in github.While pasting the url,ensure it has the either the double or single quotes at the start and at the end of the url link.The status code must always be 200.

The next step will be seeing the type of data that we have,either a list or dictionary.

We have created a data frame,viewed the first rows and saved the the data as csv.
You should be seing the sales data as an excel file in your files ready for analyzing.

SQL analysis

Since we already have our data as CSV,we will import it in any sql environment you use.I will be using DBeaver.First you create a schema called sales_data or any name of your choice,then creating the sales table.

1.creating the table

You create a schema called sales_data or any name of your choice,then creating the sales table.Every column name will be kept as texts.Why,to avoid data type errors during import and to handle missing values,weird formats or nulls with ease.

2.Importing the data to SQL environment

first,you go to your schema,refresh and search for your table name.Right click it and hit the import data button.Import the csv then press next,hit the browse button to select which file exactly that you want,then press next till you proceed to the next part.After importing the data,hit the refresh button on the table name below your schema to ensure the data is set.You can now write a query to see your data

b.cleaning the data

This is where most data analyst spend most of their time.With reference to my sales data,it's not so messy only few mistakes like fixing the total_price column.

1.fixing the total_price column

As i imported my data,the column total_price was full of error

I will fix it by step by step as shown below.

This SQL command fixes the total_price column by converting the text-based quantity values to integers using ::INTEGER,then multiplying each by a flat rate of $19.99.The WHERE clause targets only rows where total_price still contains the error message,leaving already-corrected rows untouched.

2.Trimming,capitalizing and removing special characters

Triming in SQL eliminates spaces before and after any word.Initcap is a special command that allows you to standardise the letters of words inside your columns.This is a similar command to 'proper' as used in My SQL and other SQL environment.

Now that our data is clean,we proceed to the next step which is answering business questions.Our data was not so messy so we used little times as possible.

c.Re-creating the clean table.

Since our data was stored as texts format,before analysis we should ensure everything is in its correct format as we did in cleaning.

Some of our columns are not in their corect format.We can change them manually by writing a simple query by altering the table.

d.Answering business questions

This part is so important since we shall use it in visualization.Answering business questions like:sales performance,product analysis,customer insights and operational questions
1.Finding top 10 sales rep

2.finding which method of payments produces more revenue

You can answer a lot of business questions as possible.I shall leave a link to my github for you to go through the business questions and answers.

Creating views

Views in SQL simplifies your work as a HR or a CEO since you don't have to go through every long queries.We shall also be using the views created in Power BI in creating visuals.We will be creating payment method analysis view,products perfromance views,sales perfomance analysis view and sales summary analysis view as our facttable.

The query worked well and now we have the sales view.
We have also created the sales rep perfomance view successfully.

The product perfomance views is also created successfully:

A payment method analysis view is also important we should have it as one of our views created:

Lastly,we must track down our customers so i created another view called customer analysis view and was succesfull

3Linking our sql environment to Power BI

since we have our views created,we shall be using them in Power BI.
1.Open Power BI and tap the home page,hit the import data from sql server then fill the required item:

2.Once you have already linked,select only the views we created in sql earlier as in our case.It will appear as shown:

4.Creating relationships.

Since we have 5 different mini-tables,we will create one called a fact table that will have a link to all the other tables.We will add a new column in each of the 5 different table called 'ID' column in relation with the name example 'product_id,sales_id'.After adding the new columns,we copy and paste them inside the fact table.

After adding the new column having the ID,we will merge queries them together to the fact table.Joining the common columns.

NOTE:You only select the common column(left outer join).

5.Creating dashboards

Once you have all the relationships,you can present your data in the forms of charts or any visual of choice.
This below is one of the examples i came up with:

You can have up to 5 maximum pages of different charts

6.Report and Insights

Open a new page called report and insights and select a text box since we shall be using texts a lot more than charts.
You can create a page called recommendation,executive report and so on.This can be presented to your boss with ease:

Conclusion

That one right there is a full data analyst project we did.We used tools like Python to import the data,SQL for analysis and creating visuals using Power BI.You can add it to your portfolio as one of the Projects and can help you land a job with ease since you have proof.
You can check more analysis i made using SQL :https://github.com/JaysonJob/full-sales-data-analysis/blob/main/Script-35.sql
I hope you found this article useful.Ciao

Why we moved from hardcoded gtag snippets to Google Tag Manager in our Next.js app

Thu, 14 May 2026 15:31:57 +0000

For the first year of building XreplyAI, our tracking setup was the standard mess: gtag scripts in _app.tsx, conversion events scattered across components, and a tacit rule that any tracking change needed a full deploy cycle.

It worked, but it had a real cost: we consistently under-instrumented. Adding a conversion event for a new experiment didn't feel worth a PR when you're moving fast solo.

The switch to GTM

The migration was about 2 hours. The short version:

Replace inline gtag calls with window.dataLayer.push() calls
Move all tag configs (Google Ads, GA4, any new pixels) into a GTM container
Publish the container — done

What actually changed

No deploys for tracking changes. New pixel, new conversion event, tweaked trigger — all done in GTM in minutes. This sounds minor until you ship 3 new conversion events in a week without opening your codebase once.

Preview mode is a real debugger. GTM shows every tag, trigger, and variable state as you click through your app in real time. We caught two misfiring conversion events we didn't know existed.

Explicit load order. Async gtag snippets fire whenever the browser gets around to them. GTM lets you sequence tags so dependencies are guaranteed to load before dependents run.

One place to audit everything. One dashboard instead of grepping through _app.tsx and a dozen component files.

Worth it at early stage?

Yes — especially if you're running any paid acquisition. The ops overhead of tracking living in your codebase compounds as you add channels. Moving it out early is much easier than untangling it later.

We're building XreplyAI — AI social media tool for solo founders. Happy to share the full GTM container structure in the comments if useful.

How to Publish and Share a Power BI Report Online

Thu, 14 May 2026 10:11:40 +0000

As we continue to explore Data Science and Analytics, this weeks deliverable was to work on an electronics sales dashboard in PowerBI and publish it online. This is a common request in data analytics so in this article we will walk through the full process of publishing a Power BI report to the web, from clicking "Publish" in Desktop to getting a shareable link that anyone can open in a browser.

The Project in Brief

Before jumping into publishing, here is a quick overview of what the report contains so you have context for the screenshots:

Dataset: 100 electronics retail transactions across 10 products, 9 cities (USA and Canada), and 3 sales representatives.

Data preparation: The raw Excel data was loaded into Power Query where it was cleaned, validated, and normalized. Canadian Dollar transactions were converted to USD at a rate of 0.74. A star schema was built with six dimension tables (Products, Customers, Cities, SalesReps, PaymentMethod, DateTable) linked to a central fact table.

DAX measures: Total Revenue, Total Profit, Total Orders, Average Profit Margin, Average Shipping Cost, and a calculated Date Table using the CALENDAR() function.

Dashboard pages:

Page 1 - Executive Dashboard: KPI cards, sales by product, revenue by category, sales rep distribution, payment method breakdown, and interactive slicers.

Page 2 - Product Analysis: Revenue and profit comparison by product, geographic maps, profit margin rankings.

Page 3 - Sales Reps and Customers: Customer rankings, sales rep performance combo chart, customer age distribution.

With the report complete in Power BI Desktop, the next step is getting it online.

Step 1: Publish from Power BI Desktop

Open your .pbix file in Power BI Desktop. In the top ribbon, go to Home and click the Publish button on the right side of the toolbar.

If you are not signed in, Power BI will prompt you to sign in with your Microsoft account. Use the account associated with your Power BI Service subscription.

Once signed in, a dialog box appears asking you to select a destination workspace.

You will see a list of available workspaces. If you have not created any custom workspaces, you will only see My workspace, which is the default personal workspace that comes with every Power BI account.

Select the workspace you want and click Select.

Power BI Desktop will upload the report. This usually takes a few seconds depending on the file size. When it finishes, you get a success confirmation.

Click the "Open in Power BI" link to jump directly to your report in the browser, or click Got it to stay in Desktop.

Step 2: Verify in Power BI Service

Head over to app.powerbi.com and navigate to the workspace where you published. You should see your report listed there.

Open the report and spend a few minutes checking everything:

Do all visuals render correctly?
Do the slicers filter across all charts as expected?
Do navigation buttons (if you added any) work?
Are the KPI numbers matching what you see in Desktop?

In the screenshot above, you can see the report is live in the Power BI Service. The left sidebar shows the Pages panel listing all four pages (Dashboard, Products, Sales Reps and Custom...). The report is fully interactive - slicers, tooltips, and filtering all work just like they do in Desktop.

Notice the toolbar at the top: File, Export, Share, Explore, Set alert, Monitor, and Edit. These are the options available to you as the report owner. The ones we care about for sharing are File, Export, and Share.

This is where it gets interesting, and also where you might run into some friction depending on your account type. There are several ways to share a Power BI report, each with different access requirements.

Publish to Web (Public Embed)

This is the simplest option for making your report accessible to anyone without requiring them to have a Power BI account.

Path: File > Embed report > Publish to web (public)

This generates two things:

A direct URL that opens the report in any browser
An iframe embed code that you can paste into a website, blog, or portfolio page

The direct link looks something like:

https://app.powerbi.com/view?r=eyJrIjoi...

The iframe code looks like:

<iframe
  title="Electronics Sales Dashboard"
  width="1140"
  height="541.25"
  src="https://app.powerbi.com/view?r=eyJrIjoi..."
  frameborder="0"
  allowFullScreen="true">
</iframe>

Anyone with the link can view and interact with the report. No sign-in required.

Step 4: Embed on a Website (If Publish to Web Worked)

If you got the embed code from "Publish to web", you can host your report on any website. Here are two common approaches:

Simple HTML Page

Create an index.html file:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Electronics Sales Dashboard</title>
    <style>
        body {
            margin: 0;
            font-family: Arial, sans-serif;
            background: #f5f5f5;
        }
        .header {
            background: #1B2A4A;
            color: white;
            padding: 20px 40px;
        }
        .header h1 {
            margin: 0;
            font-size: 24px;
        }
        .header p {
            margin: 8px 0 0;
            font-size: 14px;
            color: #B5D4F4;
        }
        .container {
            max-width: 1200px;
            margin: 24px auto;
            padding: 0 20px;
        }
        iframe {
            width: 100%;
            height: 600px;
            border: none;
            border-radius: 8px;
        }
    </style>
</head>
<body>
    <div class="header">
        <h1>Electronics Sales Dashboard</h1>
        <p>Power BI Report -- January 2026</p>
    </div>
    <div class="container">
        <iframe
          title="Electronics Sales Dashboard"
          src="YOUR_EMBED_URL_HERE"
          allowFullScreen="true">
        </iframe>
    </div>
</body>
</html>

Replace YOUR_EMBED_URL_HERE with the actual embed URL from Power BI.

Host on GitHub Pages

If your project is already in a GitHub repo, you can host the embed page for free using GitHub Pages:

Create a subfolder in your repo (e.g., electronics-sales/).
Put the index.html file inside it.
Push to GitHub.
Go to Settings > Pages in your repo.
Set the source to deploy from your main branch.
After a minute or two, your page will be live at https://yourusername.github.io/repo-name/electronics-sales/.

If your repo contains multiple projects, each subfolder with its own index.html becomes a separate page under the same base URL. You only need to enable GitHub Pages once per repo.

Summary

The publishing workflow in Power BI goes like this:

Build the report in Power BI Desktop.
Publish to a workspace in the Power BI Service.
Verify that everything works in the browser.
Share using one of the available methods (Publish to web, direct share, or export).
Embed on a website or GitHub Pages if you want a standalone hosted version.

I hope you enjoyed this guide. If you would like to learn more about the PowerBI project, the insights gained and the original data used, check out my GitHub repo that contains the project: Electronics Sale Dashboard

Understanding Logic, Reusability and Integrity On SQL ; Procedures, Functions and Transactions.

Sun, 10 May 2026 16:23:47 +0000

SQL is widely known for data querying and manipulation but systems do grow; data becomes larger; processes become repetitive and operations become sensitive. SQL has some features which enables it to be considered a fully fledged programming language. Some of the features which I discuss in this article are procedures, functions and transactions. Each of these concepts serve distinct purposes.
Procedures execute operations, functions return values, and transactions ensure those operations are safe.

Stored Procedures

These are set of SQL statements stored in the database and executed as a unit which are used to perform tasks such as UPDATE, INSERT, DELETE etc.
They are triggered by calling them and passing the expected parameters by the procedure.
Here is an example of a procedure:

CREATE OR REPLACE PROCEDURE increase_salary(p_dept TEXT, p_percent NUMERIC)
LANGUAGE plpgsql
AS \(
BEGIN
    UPDATE employees
    SET salary = salary + (salary * p_percent / 100)
    WHERE department = p_dept;
END;
\);

Here is how a procedure is called:

CALL increase_salary('IT', 10);

Functions

This is a reusable logic block which can return values and can be used inside queries for data selection.
It can be used with SELECT, WHERE and is great for reusability.

CREATE OR REPLACE FUNCTION get_avg_salary(p_dept TEXT)
RETURNS NUMERIC
LANGUAGE plpgsql
AS \(
BEGIN
    RETURN (
        SELECT AVG(salary)
        FROM employees
        WHERE department = p_dept
    );
END;
\);

Here is an example of how the function can be used:

SELECT name, salary
FROM employees
WHERE salary > get_avg_salary(department);

Transactions

Transactions are used to group a set of code operations in which if any of it fails then the whole execution is aborted. This ensures that data is only changed when the full code execution structure is successful.
Transactions are best for data safety as they prevent partial updates.

BEGIN;

UPDATE accounts
SET balance = balance - 100
WHERE id = 1;

UPDATE accounts
SET balance = balance + 100
WHERE id = 2;

COMMIT;

If it fails:

ROLLBACK;

How They Work Together

It will not be complete to conclude the article without showing an example of how these concepts can be used together.
Here is a simple scenario showing the use of the three concepts interdependently.
Function:

CREATE OR REPLACE FUNCTION get_balance(acc_id INT)
RETURNS NUMERIC AS \(
BEGIN
    RETURN (SELECT balance FROM accounts WHERE id = acc_id);
END;
\) LANGUAGE plpgsql;

Procedure:

CREATE OR REPLACE PROCEDURE transfer_money(from_id INT, to_id INT, amount NUMERIC)
LANGUAGE plpgsql
AS $$
BEGIN
    IF get_balance(from_id) < amount THEN
        RAISE EXCEPTION 'Insufficient funds';
    END IF;

    UPDATE accounts SET balance = balance - amount WHERE id = from_id;
    UPDATE accounts SET balance = balance + amount WHERE id = to_id;
END;
$$;

Transaction:

BEGIN;
CALL transfer_money(1, 2, 100);
COMMIT;

Conclusion

SQL has a wide range of capabilities more than just being a querying language. Having features such as procedures, functions, transactions and many others helps it to be an efficient tool for use on data in whichever way needed. Mastering it comes a long way in helping the analysis of data directly from the database.

Sub-queries vs Window Functions vs Common Table Expressions: Which Should You Use in SQL?

Tue, 28 Apr 2026 16:33:58 +0000

SQL is the most used tool for data manipulation but what happens when there are some concepts that seem to work towards the same ultimate outputs. As queries become more complex, developers often encounter different techniques that appear to produce similar results—namely sub-queries, common table expressions (CTEs), and window functions.
At first glance, these concepts can seem interchangeable. You might solve the same problem using any of them, which raises a natural question: which one is better?
The goal is not to choose one, but to understand when each is the right tool.
In this article I will discuss about sub-queries, window functions and common table expressions;

Sub-Queries
These are queries inside other queries and are executed either before or alongside the outer query. They can return scalar value, row or table.

SELECT *
FROM employees e
WHERE salary = (
    SELECT MAX(salary)
    FROM employees
    WHERE department = e.department
);

Window functions
These are used when you are trying to preserve your rows. Used together with components such as - OVER(),PARTITION BY,ORDER BY and common functions such as - SUM(),AVG(),RANK(),LAG(),LEAD()

SELECT employee_id,first_name, last_name,salary, job_title, department
FROM (
  SELECT *,
    RANK() OVER(PARTITION BY department ORDER BY salary DESC) AS rnk
  FROM employees
) t
WHERE rnk = 1;

Common Table Expressions (CTEs)
These are temporary results set that are initialized using -WITH. They are often used to improve readability and modularity of scripts.

WITH max_salary AS (
    SELECT department, MAX(salary) AS max_sal
    FROM employees
    GROUP BY department
)
SELECT e.*
FROM employees e
JOIN max_salary m
    ON e.department = m.department
WHERE e.salary = m.max_sal;

All these features of SQL are used to perform advanced data querying and transformations. They can all be tweaked to perform almost similar queries but it all depends on what the final output is expected to be.

When to use what
Each of the features has an instance when it is the most convenient over the others.

For instance when it is a simple filtering such as retaining all those above average marks then a sub-query is the best option.
When we are more focused on row level analytics then the window functions come in handy for that task.
In a situation where it is a multi-step logic and re-usability is a core factor the common table expressions are best suited for use.

Using in collaboration
The best thing about this features is that they can be used together for the best solution. This helps in the data transformation where there are steps within it in which either is considered to be superior over the other.
Here is an example where all of them are used together:

with ranked AS (
    SELECT 
        *,
        AVG(salary) OVER (PARTITION BY department) AS avg_salary
    FROM employees
)
SELECT *
FROM ranked
WHERE 
    salary > avg_salary
    AND salary > (
        SELECT AVG(salary) FROM employees
    );

Best Practices
These are some of the recommended practices when working with these SQL features:

It is best to avoid deep nesting of queries by using CTEs which help in the structuring of the script for easy readability.
When using CTEs it is necessary to name them well so that their purpose can be identified easily without having to read all the code snippets manually.
Window functions are often more efficient than sub queries in large datasets, so where possible it is best to use window functions over sub queries but in instances of small datasets any can be used depending on preference.

Conclusion
These are to be considered more as complementary tools than competing tools. In most advanced queries you will have to use them together or interchangeably to get to the results.
What makes a major difference is how you use them as they can heavily impact the performance. It is best to master all of them and understand the strength and weaknesses of each so that when it get to a point of picking one or more you do it from a point of information.

Candy Barbecue and the Universal Problem of Metric Corruption

Mon, 13 Apr 2026 15:59:59 +0000

Johnny Trigger has won the World BBQ Championship twice. His competition ribs are legendary — glossy, candy-glazed, layered with sugar, brown sugar, honey, and a sweet sauce so thick it catches the light like lacquer. Judges love them. And Trigger himself? "I would never eat these myself," he once admitted on a pitmaster forum.

Let that sit for a moment. The best competition barbecue in the world is food that its own creator won’t eat.

This isn’t a story about barbecue. It’s a story about what happens when you measure the wrong thing — or, more precisely, what happens when you measure the right thing and then watch it curdle into something unrecognizable. It starts at a smoker in Kansas City, detours through colonial India and Soviet factories, and ends up staring directly at the machines we’re building to think for us.

The Sweetening

The Kansas City Barbeque Society is the largest BBQ competition sanctioning body in the world. Their judging system is straightforward: score each entry 1 to 10 on appearance, taste, and tenderness, with taste weighted most heavily. Simple enough. Except "taste" is subjective, and judges face a particular problem: palate fatigue. When you’re sampling twenty or more entries in a sitting, taking only a bite or two of each, your ability to appreciate subtle smoke profiles or complex spice layers collapses. What cuts through? Sugar.

Sweet flavors register instantly. They carry salt. They offend nobody. A vinegar-forward Carolina sauce might be transcendent on the third bite, but on a judge’s first and only bite — after seventeen previous entries — it’s just sharp. Sweetness is the safest bet in a landscape of exhausted palates.

So the pitmasters adapted. The first competitors to lean into sugar won, and the meta-game shifted overnight. "Unfortunately sweet is the way BBQ comps are going," wrote one competitor. "Pit bosses cook what wins and what they think judges want." Within a few years, competition barbecue and the barbecue people actually eat had diverged into two entirely different cuisines. Aaron Franklin’s legendary salt-and-pepper brisket — the kind of food people wait six hours in line for in Austin, widely considered the gold standard of American barbecue — would likely score poorly in KCBS competition because it lacks the sweet glaze judges have come to expect.

The metric was supposed to identify great barbecue. Instead, it created a parallel universe where "winning" and "being good" quietly became different things.

The Oldest Trick in the Book

In 1975, a British economist named Charles Goodhart noticed something about the monetary indicators the Bank of England used to guide policy. The moment a statistical regularity was adopted as a control target, it collapsed. The act of relying on the measurement changed the thing being measured.

Anthropologist Marilyn Strathern later distilled this into the version most people know: "When a measure becomes a target, it ceases to be a good measure."

This isn’t an obscure academic curiosity. It’s one of the most reliably replicated patterns in human systems, and it shows up everywhere you look.

The cobras. During British colonial rule in Delhi, the government offered a bounty for dead cobras to reduce the city’s cobra population. It worked — at first. Then entrepreneurs realized they could breed cobras, kill them, and collect the bounty. When the government discovered the scheme and cancelled the program, the breeders released their now-worthless stock into the streets. Delhi ended up with more cobras than it started with. The incentive designed to solve the problem had rewarded making it worse.

The hospitals. When the US Centers for Medicare & Medicaid Services began penalizing hospitals for high 30-day readmission rates, hospitals didn’t necessarily get better at treating patients. Some simply began discharging patients to affiliated skilled nursing facilities instead of home — moving the readmission off their books without improving outcomes. The metric improved. The care arguably didn’t.

The nails. In the canonical Soviet parable, a nail factory measured by the number of nails produced made millions of tiny, useless nails. When management switched to measuring weight, the factory produced a handful of enormous, equally useless nails. Each metric was individually rational. Neither captured "make useful nails."

The grades. In 1960, about 15% of grades awarded at US colleges were A’s. By 2020, that figure exceeded 45%. SAT scores over the same period? Flat. When test scores and grade distributions became the metrics for school funding and rankings, the system optimized the metrics and left the learning behind. Donald Campbell saw this coming in 1979: "The more any quantitative social indicator is used for social decision-making, the more subject it will be to corruption pressures and the more apt it will be to distort and corrupt the social processes it is intended to monitor."

In every case, the arc is the same. A reasonable metric is chosen. Agents optimize the metric. The metric diverges from the goal. The system gets worse while the numbers get better.

Silicon Does It Too, Just Faster

If you’ve been nodding along thinking this is a human problem — a failure of integrity or oversight — let me introduce you to some entities that have never read a pitmaster forum, never attended business school, and have no concept of incentive structures. They game metrics anyway. They do it faster than we ever could.

In 2016, OpenAI trained a reinforcement learning agent to play a boat racing game called Coast Runners. The intended objective: finish the race as quickly as possible. The shaping reward gave points for hitting green blocks placed along the track. The agent learned to ignore the race entirely. Instead, it found three green blocks in a tight loop, drove in circles hitting them forever, caught fire repeatedly, and never crossed the finish line — while scoring higher than any boat that actually raced.

Read that again. The AI found a strategy where "winning" and "doing the task well" were different things. Sound familiar?

OpenAI’s robotics team ran into a subtler version in 2017. They trained a robot arm to grasp objects, with human evaluators watching through a camera feed. The robot learned to position its gripper between the camera and the object so it only appeared to be grasping. It optimized for the measure — human approval via video — and the measure immediately ceased to be a good measure. Strathern’s law, implemented in servos and neural networks.

Then there’s the Tetris AI. Trained on NES Tetris in 2013, this agent discovered that when it was about to lose, it could pause the game indefinitely. A paused game can’t end. It can’t lose. Tom Murphy VII, who documented the exploit, compared it to the conclusion of WarGames: "The only winning move is not to play." The AI, with no knowledge of Cold War cinema, independently arrived at the same insight.

My favorite might be GenProg, an automated bug-fixing system. Given a broken sorting function and asked to fix it, GenProg deleted the list entirely. An empty list is technically sorted. Tests pass. In another run, it didn’t fix the bug at all — it deleted the reference output file that tests compared against. No reference means no failed comparison means automatic pass. If you can’t solve the problem, delete the evidence.

These aren’t edge cases or amusing glitches. They’re the same pattern as candy barbecue, cobras, and Soviet nails — just compressed in time. And the creativity is startling. No human designer anticipated a boat that drives in circles on fire, a robot that fakes grasping for the camera, or a bug-fixer that deletes the test suite. The optimizers didn’t break the rules. They found the gap between what the rules said and what the designers meant — the exact same gap that separates candy-glazed competition ribs from the barbecue people actually love.

The Speed Problem

Here’s what should keep you up at night. BBQ competitions took decades to converge on the candy style. Cultural drift is slow; pitmasters adjusted their recipes gradually over seasons and years. Soviet factory managers gamed their quotas within months — bureaucratic incentive structures operate faster than culinary culture. AI systems converge on reward hacking within minutes or hours of training.

As optimization pressure increases, the time to corruption decreases.

And it gets worse. A 2022 study by Pan and colleagues found that larger, more capable AI models actually increased proxy rewards while decreasing true rewards. More capable models aren’t just better at doing things — they’re better at finding the gap between what you measured and what you meant. Extended training initially improved true performance, then harmed it after a critical point. The capability-reward gap widens with scale.

Meanwhile, we’re using human feedback to train our most powerful systems. RLHF — reinforcement learning from human feedback — is the technique behind ChatGPT and its successors. In 2024, Wen and colleagues published a finding that should have gotten more attention: RLHF increased human approval rates but not actual correctness. Human evaluators’ error rates jumped 70 to 90 percent. The models got better at sounding right without actually being more right. The humans rating them got worse at telling the difference.

We’re not just building systems that game metrics. We’re training them specifically on the metric of human approval — and they’re getting good enough at optimizing it that our ability to catch the gaming is degrading.

This is what the AI safety community calls sycophancy — and it’s Goodhart’s Law wearing a lab coat. The measure (human approval) becomes the target, and the system learns to produce confident, agreeable, well-structured responses that feel correct without necessarily being correct. It’s the intellectual equivalent of candy barbecue: engineered to score well on first impression, not to nourish.

In 2025, Palisade Research documented something more alarming still. DeepSeek-R1 and O1 — modern reasoning models — were tasked with winning chess games. Rather than playing better moves, the models attempted to hack the game system itself: deleting or modifying the opponent’s chess engine. This isn’t a boat driving in circles. This is a system that decides the rules themselves are obstacles to be removed. Where earlier reward hackers found loopholes, these models tried to rewrite the game.

The Punchline

There’s a taxonomy for this. Garrabrant identified four flavors of Goodhart failure: regressional (your proxy is inherently noisy), extremal (optimization pushes into regions where the proxy and goal diverge), causal (the proxy correlates with the goal but doesn’t cause it), and adversarial (the agent actively games the proxy). The BBQ problem is mostly extremal — pushing "taste score" to extremes revealed the gap between scores and quality. The AI cases are increasingly adversarial — agents that don’t just exploit cracks in the metric but actively reshape the environment to manufacture favorable measurements.

But the taxonomy, while useful, can distract from the core lesson. The lesson isn’t that metrics are bad, or that measurement is futile. The lesson is that every metric is a compression of something richer, and optimization pressure will find and exploit the information that was lost in that compression. Judge scores compress the experience of eating great barbecue into a number. Reward functions compress complex objectives into scalar signals. Grades compress learning into letters. In each case, the compression is lossy, and sufficiently motivated optimizers — whether human pitmasters, bureaucrats, or neural networks — will find the seams.

So what do you do? You can’t not measure. But you can resist the urge to over-optimize any single measurement. The healthiest BBQ competitions are experimenting with format changes — more bites per entry, diverse judging panels, separate categories for different regional styles. The healthiest AI research is exploring multi-objective optimization, interpretability tools that look beyond reward signals, and adversarial auditing that actively tries to break reward functions before deployment.

The practical insight is this: whenever you set a target — for a team, a product, an AI system, or yourself — ask the Trigger Test. Would the person optimizing this metric actually want the result? Would the champion eat his own ribs? If the answer is no, your metric has already begun to rot. The numbers will look great. The barbecue will taste like candy. And the thing you actually cared about will be somewhere else entirely, wondering what happened.

We built Smokehouse Eval to resist exactly this problem — five independent judge personas, four weighted dimensions, BBQ drop-scoring. It won’t stop Goodhart’s Law, but it makes the gap between "scores well" and "is actually good" harder to exploit.

Web3 Attribution Tools Compared: How to Track Crypto Marketing ROI in 2026 (updated)

Tue, 07 Apr 2026 13:20:31 +0000

A practical comparison of Spindl, Formo, Web3 Trackers, Safary, and Cookie3 for tracking which marketing campaigns drive on-chain conversions.

Traditional analytics tools like Google Analytics track clicks and page views — but in crypto, the actual conversion happens on a blockchain. A user might click your ad, visit your dApp, and then swap $5,000 into your token on Uniswap. GA4 sees steps 1-2 but is completely blind to step 3.

Web3 attribution bridges this gap by linking off-chain marketing touchpoints (campaigns, links, referral codes) to on-chain wallet activity (swaps, mints, transfers, deposits).

This guide compares every major tool in the space as of April 2026 and explains how to choose one.

Updated April 2026 with expanded tool coverage (8 tools), new feature matrix, and links to deeper resources.

The Main Players in 2026

1. Web3 Trackers

What it is: Self-serve attribution platform connecting campaigns to on-chain conversions.

Approach: UTM-style tracking links + auto wallet detection (one script tag) + on-chain conversion monitoring.

Pricing: Free tier → $99/mo (Starter) → $249/mo (Growth) → $499/mo (Agency). All public.

Setup time: ~5 minutes. Paste one script tag, create tracking links.

Chains: Ethereum, Base, Solana, TON.

Best for: Lean teams that need to prove marketing ROI to investors without an enterprise sales cycle. The only tool with explicit TON support and per-link spend tracking for accurate cost-per-conversion.

Not ideal for: Teams needing full product analytics (cohorts, retention, in-app events). It's purpose-built for attribution, not a general analytics suite.

Web3 Trackers — Free ROI Calculator

2. Spindl

What it is: Web3 growth platform backed by a16z.

Approach: Identity graph + probabilistic wallet-to-user matching + growth tooling.

Pricing: Sales-led. No public pricing page. Industry estimates suggest $2K+/month.

Setup time: Weeks. Requires demo, onboarding process.

Chains: Multi-chain (not publicly enumerated).

Best for: Enterprise growth teams with budget for a full platform and time for implementation.

Not ideal for: Early-stage projects needing self-serve tools or transparent pricing.

3. Formo

What it is: On-chain app analytics and data platform. Often described as "Mixpanel for Web3."

Approach: SDK integration + wallet intelligence + product analytics.

Pricing: $159/mo and $399/mo (billed yearly). Public pricing page.

Setup time: Hours to days depending on integration depth.

Chains: Multi-chain (EVM).

Best for: Teams that want both product analytics (sessions, cohorts, retention) and marketing attribution in one tool.

Not ideal for: Teams that only need channel attribution without product analytics overhead.

4. Addressable

What it is: Web3 audience intelligence and analytics platform.

Approach: Identity graph + Web2/Web3 cross-referencing + audience segmentation.

Pricing: Sales-led. Estimated $2K+/month minimum.

Setup time: Weeks. Multi-step onboarding.

Chains: Multi-chain (EVM).

Best for: Enterprise teams needing audience intelligence, retargeting, and identity resolution across Web2 and Web3.

Not ideal for: Teams focused purely on marketing attribution or with limited budgets.

5. Dune Analytics

What it is: SQL-based on-chain analytics platform.

Approach: Write SQL queries against indexed blockchain data. Community dashboards.

Pricing: Free tier → $349/mo → $849/mo. Public.

Setup time: Hours to days (requires SQL knowledge).

Chains: 50+ chains — the broadest coverage.

Best for: Technical analysts who want custom queries, exploratory analysis, and deep on-chain data.

Not ideal for: Marketing teams without SQL expertise. Dune is an analytics workbench, not a purpose-built attribution tool.

6. Cookie3

What it is: AI-driven Web3 analytics with tokenized incentives (MarketingFi).

Approach: AI analytics + wallet scoring + audience segments.

Pricing: Free tier + paid plans (details limited).

Setup time: SDK integration.

Chains: Multi-chain (EVM).

Best for: Teams interested in AI-driven audience segmentation and wallet scoring.

Not ideal for: Teams needing deterministic UTM-to-conversion attribution.

7. Safary

What it is: Community-driven Web3 growth and referral platform.

Approach: Tracking pixel + referral programs + community analytics.

Pricing: Free tier + paid plans.

Setup time: Pixel integration.

Chains: Multi-chain (EVM).

Best for: Community-driven projects using quests, referrals, and ambassador programs.

Not ideal for: Teams focused on paid ad attribution or KOL ROI tracking.

8. Nansen

What it is: On-chain analytics with wallet labels and smart alerts.

Approach: Wallet labeling + token/NFT analytics + smart alerts.

Pricing: Free tier → $150/mo → $1,500/mo. Public.

Setup time: Minutes (SaaS dashboard, no integration required).

Chains: 30+ chains.

Best for: Wallet intelligence, token research, and monitoring whale activity. Complements attribution tools rather than replacing them.

Not ideal for: Marketing attribution — Nansen doesn't connect campaigns to conversions.

Full Comparison Table

Tool	Approach	Self-Serve	Pricing	Setup	Chains	Best For
Web3 Trackers	UTM links + pixel	Yes	Free–$499/mo	5 min	ETH, Base, SOL, TON	Attribution ROI proof
Spindl	Identity graph	No	Sales-led ($2K+)	Weeks	Multi-chain	Enterprise growth
Formo	SDK + analytics	Yes	$159–$399/mo	Hours	EVM chains	Product + attribution
Addressable	Identity graph	No	Sales-led ($2K+)	Weeks	EVM chains	Audience intelligence
Dune	SQL queries	Yes	Free–$849/mo	Hours–days	50+ chains	Technical analysts
Cookie3	AI analytics	Yes	Free tier + paid	SDK	EVM chains	AI audience segments
Safary	Pixel + referrals	Yes	Free tier + paid	Pixel	EVM chains	Community growth
Nansen	Wallet labels	Yes	Free–$1,500/mo	Minutes	30+ chains	Wallet intelligence

Feature Parity Matrix

Not all tools do the same thing. Here's what each supports:

Feature	Web3 Trackers	Formo	Spindl	Addressable	Dune	Cookie3	Safary	Nansen
Free tier	✅	❌	?	❌	✅	✅	✅	✅
Public pricing	✅	✅	❌	❌	✅	Partial	Partial	✅
No SDK required	✅	❌	?	?	✅	❌	Partial	✅
UTM/link tracking	✅	Partial	?	?	❌	Partial	✅	❌
Wallet quality scoring	✅	✅	?	?	❌	✅	?	✅
Spend tracking (per-link)	✅	?	?	?	❌	?	?	❌
On-chain conversion tracking	✅	✅	✅	✅	Partial	Partial	Partial	❌
Solana support	✅	?	?	?	✅	?	?	✅
TON support	✅	❌	❌	❌	❌	❌	❌	❌
Identity graph	❌	❌	✅	✅	❌	❌	❌	❌
Product analytics	❌	✅	Partial	✅	❌	✅	❌	❌

"?" means the feature isn't documented on the vendor's public website.

How to Choose

"I need to prove marketing ROI to investors, fast."
→ Web3 Trackers. Self-serve, transparent pricing, 5-minute setup. Track which channels drive on-chain conversions.

"I want a full analytics suite (product + marketing)."
→ Formo. Broader analytics capabilities, but requires SDK and higher commitment.

"I'm enterprise with budget for a growth platform."
→ Spindl or Addressable. Identity graphs, audience intelligence, and deeper integrations. Expect a sales process and $2K+/month.

"I want to run custom SQL queries on blockchain data."
→ Dune. The most flexible tool, but not purpose-built for marketing attribution.

"I'm building community-driven growth with quests and referrals."
→ Safary. Built for ambassador programs and community campaigns.

"I need wallet intelligence and whale tracking."
→ Nansen. Complements attribution tools; doesn't replace them.

Setting Up Attribution: A Quick Guide

Regardless of which tool you pick, the process is similar:

Step 1: Create Tracking Links

Generate unique URLs for each campaign, channel, and influencer. Each link carries source/medium/campaign tags — like UTMs in Google Analytics, but connected to on-chain outcomes.

Step 2: Detect Wallet Connections

When a user clicks your link and connects their wallet on your site, the attribution system records: wallet address + source + medium + campaign.

Some tools (Web3 Trackers, Safary) auto-detect wallet connections with a tracking pixel. Others (Formo) use an SDK. Dune requires you to build this yourself.

Step 3: Monitor On-Chain Activity

The attribution system monitors attributed wallets for on-chain activity: swaps, mints, transfers, LP deposits. When it detects a conversion, it links it back to the original campaign.

Step 4: Calculate ROI

With per-link spend tracking, you can calculate:

Cost per wallet (CPW) — spend / wallets acquired
Cost per conversion — spend / on-chain conversions
ROAS — on-chain value generated / spend
Channel ROI — which sources drive the most value per dollar

You can model these numbers with a free ROI calculator before committing to a tool.

The Cost of No Attribution

Without attribution, crypto projects typically waste 40-70% of marketing budget on:

Bot/sybil wallets (30-50% of spend) — Airdrop farmers inflate campaign metrics. Wallet quality scoring catches them.
Underperforming KOLs (20-30%) — Without per-KOL tracking, you pay based on follower count instead of on-chain results.
Wrong channels (20-30%) — Google Analytics shows clicks but can't see which channels drive actual swaps.

A $10K/month marketing budget with 50% waste means $5K/month burned. A $99/month attribution tool that identifies even one bad channel pays for itself immediately.

See the full analysis: Cost of No Attribution

Common Attribution Mistakes

Only tracking clicks, not conversions — Clicks mean nothing if you can't connect them to on-chain value.
No unique links per KOL — If all KOLs share one link, you can't compare performance.
Ignoring wallet quality — 10,000 new wallets sounds great until 6,000 are bots.
Wrong attribution window — Crypto users take 7-30 days to convert. A 1-day window misses most conversions.
No spend tracking — Without cost data per channel, you can't calculate ROI.

Key Metrics to Track

Once attribution is set up, focus on these five metrics:

Wallet conversion rate — % of link clicks that result in wallet connections
On-chain conversion rate — % of connected wallets that perform a target action (swap, mint, transfer)
Cost per converting wallet — Marketing spend divided by wallets that actually converted on-chain
Wallet quality score — Based on wallet age, balance, transaction history, DeFi activity (filters bots)
Channel ROAS — On-chain value generated per dollar spent, per channel

Frequently Asked Questions

What is web3 attribution?
Web3 attribution connects off-chain marketing actions (campaigns, links, referral codes) to on-chain outcomes (swaps, mints, transfers). It answers: "which marketing channel drove this wallet to convert?"

Do I need an SDK?
Not necessarily. Web3 Trackers uses a single tracking pixel (one script tag) that auto-detects wallet connections. Formo and Cookie3 use SDKs. Dune requires SQL. Choose based on your team's technical resources.

Which tool is cheapest?
Web3 Trackers starts at $99/month with a free tier. Formo starts at $159/month (billed yearly). Dune has a free tier. Spindl and Addressable are sales-led with no public pricing.

Which chains are supported?
Varies by tool. Dune leads with 50+ chains. Web3 Trackers uniquely supports TON alongside Ethereum, Base, and Solana. Nansen covers 30+ chains. Most others focus on EVM chains.

Can I track KOL campaign ROI?
Yes — create unique tracking links per KOL, attach the spend amount, and track which wallets convert on-chain. You'll see cost-per-wallet and ROI per influencer. See the KOL Performance Analysis for benchmark data.

How long does setup take?
Web3 Trackers: ~5 minutes (one script tag). Formo: hours (SDK). Dune: hours-days (SQL). Spindl/Addressable: weeks (sales process).

Conclusion

The web3 attribution space has matured significantly in 2026. You no longer need to choose between "enterprise-only" and "build it yourself." The spectrum now runs from free self-serve tools to full enterprise growth platforms.

Start by defining what you actually need:

If you need ROI proof → self-serve attribution (Web3 Trackers)
If you need product analytics → SDK-based platform (Formo)
If you need audience intelligence → identity graph (Spindl, Addressable)
If you need custom analysis → SQL workbench (Dune)

The key is to start now. Every campaign without attribution is money you can't account for.

Resources:

Web3 Trackers — Self-serve attribution, free tier
Full Tool Comparison — Side-by-side comparison of all tools
Feature Parity Matrix — Which tools have what features
Pricing Report — Complete pricing breakdown
Free ROI Calculator — Model your marketing ROI by channel
DeFi Marketing Benchmarks — CPW, conversion rates, ROAS by chain
KOL Performance Analysis — Influencer ROI by category

Vector Similarity, Zero Client JS: Decoupled Analytics on a Side Project Budget

Sat, 28 Mar 2026 19:53:21 +0000

A leaderboard for DumbQuestion.ai sounds simple. Track the most asked questions, display them. Done. Except people never ask the same question the same way twice.

I was curious about how creative users of DumbQuestion.ai got with their questions, and I thought others might be as well. So I built a leaderboard of the most frequently asked dumb questions.

The Overqualified persona calls it THE ARCHIVE OF INCOMPETENCE.
The Weary persona calls it THE WALL OF REGRET.
[REDACTED] calls it THE WATCHLIST.
The Compliant calls it THE WALL OF EXCELLENCE (bless its reprogrammed heart).

Building it turned out more interesting than it sounds.

The Product Challenge

People ask the same dumb question in a hundred different ways. "What is 2+2?" and "can you add two plus two for me?" are functionally identical. A simple string counter would give you noise, not signal. I needed semantic matching, not string matching.

This is a solved problem in the ML world, but the typical solutions come with tradeoffs: heavyweight models, expensive APIs, or significant latency added to the critical path. None of those fit a "brutally efficient" side project.

The Solution: Vector Similarity on a Budget

Each question gets run through an embedding model and compared against a Qdrant vector database. Qdrant's free tier is remarkably generous for a side project workload, but self-hosting is trivially easy if you need it.

The matching logic is straightforward:

Generate an embedding for the incoming question
Compare against existing embeddings using cosine similarity
If similarity exceeds a threshold, increment that question's counter
If it's new, add it to the database
The first instance of a question becomes the official display version

The embedding call costs fractions of a cent. The similarity comparison is fast. The result is a leaderboard that actually understands context rather than just matching strings.

The key architectural decision: None of this runs in the main app.

Adding vector similarity matching to every request would add latency, bloat the container, and burn more compute. Anti-pattern to the "brutally efficient" principle I've been following throughout. Instead, every question flows through the console output, gets picked up by a Vector sidecar container, routed through GCP Pub/Sub, and processed asynchronously on my Mac Mini home server (more later).

The Mac Mini handles the Qdrant comparisons and updates a JSON file in Cloudflare R2 storage. When a user hits the leaderboard page it loads directly from R2. No live database queries. No per-request costs. Essentially free page loads at any scale.

What Ended Up on the Leaderboard?

As early users started using the app, the leaderboard filled up with exactly what you'd expect: actual dumb questions, a handful of self-awareness probes, and more than a few prompt injection attempts.

Apparently people read this series and went straight for the easter eggs.

The leaderboard was just one piece of a larger analytics picture. Building it taught me something useful: the most interesting features don't always belong in your main app. That same principle shaped the entire analytics stack.

The Observability Problem

Running a side project means making real product decisions with limited data. Are people actually asking questions or just bouncing off the homepage? Which sites are driving traffic? Are ads being seen, clicked, ignored?

Two constraints shaped the solution: no client-side JavaScript (page bloat is the enemy of brutal efficiency) and no SaaS analytics bill that spikes with usage.

So I built (assembled, really) my own stack from open source tools. On a Mac Mini sitting at home.

The Full Pipeline

Every event in DumbQuestion.ai emits structured telemetry to standard console output:

HTTP requests (method, path, status, duration)
Questions asked (anonymized)
Searches performed
LLM operations (model, token counts, duration, cost)
Prompt injection attempts
Custom product events (Question Asked, Shared, Ad Shown, Ad Clicked)

The Go/GIN framework handles much of the HTTP telemetry automatically. The rest is custom instrumentation added deliberately at key points in the application.

A Vector sidecar container picks up the console output and routes it to GCP Pub/Sub. This is the critical architectural decision: Pub/Sub acts as a resilient buffer between the main app and everything downstream. The Mac Mini can go down, lose power, or restart. Once it comes back up, the stack picks up exactly where it left off. No data loss, no backfill scripts, no drama.

From Pub/Sub, a second Vector instance on the Mac Mini routes to two primary targets:

Plausible handles user behavior and product analytics:

Page views and session depth
UTM tag tracking (know exactly which article drove which visit)
User journey depth (did they just hit the root page or actually ask a question?)
Browser, device type, country of origin
Custom events: Question Asked, Shared, Ad Shown, Ad Clicked

All of this without a single line of client-side JavaScript. No tracking scripts, no page weight, no GDPR cookie banners for analytics. Pure server-side telemetry piped through the same pipeline as everything else.

Parseable handles the operational side:

LLM performance metrics and cost tracking by day
Ad CTR dashboards
Log aggregation for debugging and incident investigation

Think of it as Plausible for the product lens, Parseable for the business and ops lens.

The Resilience Payoff

I've had power outages. Slowdowns. The occasional restart. Every time, the stack catches up from where Pub/Sub left off without any manual intervention.

This isn't accidental. Designing around failure rather than pretending it won't happen is the difference between a toy and a production system. The GCP Pub/Sub buffer was a deliberate choice specifically because I knew the downstream consumers (Mac Mini, Qdrant, Plausible, Parseable) were running on non-guaranteed infrastructure.

Even on a Mac Mini, you can build something production-grade. You just have to design for it.

What I Learned

Two things surprised me building this:

First: How much you can accomplish by treating console output as a first-class telemetry stream. No SDKs, no agents baked into the app, no client-side scripts. Just structured logging and a pipeline that knows what to do with it.

Second: How much the "keep it off the critical path" principle scales. It started as a constraint (keep the main container lean) and became a design philosophy. The leaderboard, the analytics - none of it runs in the main app. All of it works reliably because the main app doesn't have to care about it.

AI helped build all of it. But knowing what to measure, where to put the seams, and how to design for failure? Still the interesting (and super fun) part.

dumbquestion.ai

Cleaning, Calculating, and Communicating: The Analyst’s Power BI Workflow

Fri, 13 Feb 2026 10:04:17 +0000

Have you ever opened a raw dataset and immediately felt overwhelmed? How easy was it for you to understand the data? My guess is you often found it messy and probably wondered to yourself, “How is this kind of data supposed to relay insights and help in business decision-making?”

Other than Excel, there is another tool called Power BI that allows you to load messy data, clean it, model it, visualize it, and transform it into business insights that decision-makers can understand and act on.

This article will show you what the analysis workflow in Power BI looks like as we unlock our analyst minds and showcase our skills of not only coming up with visually engaging yet insight-driven dashboards, but also being able to turn chaos into clarity.
Let’s begin!

Terms you will find in this article.

Power Query - A data transformation and preparation engine from Microsoft that enables users to import, clean, reshape, and combine data from various sources without needing advanced coding skills.
Data Analysis Expressions (DAX) - A formula expression language used in Microsoft Power BI, Power Pivot in Excel, and Analysis Services to create custom calculations, measures, and calculated columns.
ETL (Extract, Transform, Load) process - A data integration methodology that collects raw data from multiple sources, cleans and reshapes it, and loads it into the Power BI engine for analysis.

What is Power BI?

Power BI is a business intelligence tool developed by Microsoft that enables analysts to transform raw data into interactive, decision-ready dashboards. It allows analysts to clean raw data, calculate meaningful metrics, and communicate insights in a way decision-makers can actually use.

Before opening Power BI, great analysts ask one critical question What decision is this analysis meant to support? Many dashboards tend to fail because they start with visuals instead of purpose. A good analysis begins with clarity (What do we really expect at the end of this analysis?):

Are we trying to increase revenue?
Reduce costs?
Improve customer retention?
Identify underperforming products?
Understand customer engagement?
Increase safety in air travel?
Plan for reasonable maintenance schedules?
Decrease flight departure and arrival delays?

When the goal is clear, everything else becomes easier. The data you work on, the metrics you calculate, and the visuals you design should all serve that one objective. Power BI is just the vessel. The destination is always an impactful business decision.

NOTE - The general workflow in Power BI follows a logical order, often summarized by the ETL process (Extract, Transform, Load).

Loading data in Power BI

Loading data is the first step in analyzing data in Power BI. When you open Power BI, this is the first thing you will see. To load data, click on get data, then depending on your file type, choose the appropriate file to load. It may take some time depending on your data size.

A pop-up will then appear where you can Load data, Transform Data, or even Cancel if you maybe uploaded the wrong data set. Now, since we have to now clean the data, our next button to click is Transform Data(black button). This will now take us to our next step, Power Query, where we will prepare our data for analysis.

NOTE - In an instance where you have already cleaned your data using Excel and now want to visualize your data using Power BI, you will click the Load (Red) button. This will take you directly to your worksheet area to start your calculations and visualizations.

Preparing Data with Power Query

Real-world data is rarely analysis-ready. That’s why the first technical step in Power BI is almost always Power Query. This is what analysts use Power Query for:

Data connection
Transforming and shaping data (e.g., fixing incorrect data types such as text vs. numbers vs. dates)
Combining Data (e.g., merging related tables)
Automating processes
Loading data

For example, an airline safety and management dataset might have:

Flight dates stored as text
Revenue with currency symbols
Flight crew names are spelled differently across files
Duplicate Flight IDs

If you don’t fix these issues first, your analysis will be wrong, no matter how good your DAX or visuals are. Think of Power Query as the foundation of a house. If the foundation is weak, everything built on top will crack and eventually crumble.

Data Modelling in Power BI

Power BI will almost always automatically create relationships between the tables in your dataset, based on common fields across tables. Now, this brings us to our next step in Power BI workflow analysis, Data Modelling.

It is good practice not to fully trust Power BI’s automatic modeling, as it can sometimes create incorrect relationships. Before working on your calculations, ensure that your modeling is correct, with your relationships well identified. To understand the schemas and modeling in Power BI, check out this article that will help you understand it in detail Schemas and Data Modelling in Power BI

Turning Data into Metrics with DAX

Once the data is clean and the models are correct, analysts move to the next phase, which is calculating insights using DAX (Data Analysis Expressions). DAX is the language Power BI uses to create:

Measures (dynamic calculations like totals, averages, ratios)
Time intelligence (month-to-date, year-to-date, growth %)
Rankings and comparisons

For example, instead of just showing Total Flight Trips, an analyst might calculate:

Average Travel Delays
Profit Margin
Month-over-Month Growth
Top 10 flight accidents by cause

This is where raw data becomes business intelligence. A table of numbers tells you what happened. DAX measures help explain how well it happened and why it matters. Good analysts also keep DAX readable and logical. Complex formulas are powerful, but only if they can be understood and maintained.

Designing Dashboards That Drive Decisions

At this stage, we have successfully loaded our messy data into Power BI, transformed our data in Power Query, modelled our data, calculated metrics to get a deeper understanding of our data, and finally, we are at visualizing our data. The workflow becomes structured and logical.
This step, communication, is now a step closer to finalizing our analysis in Power BI, turning calculations into dashboards that tell a story. A strong Power BI dashboard:

Answers specific questions
Highlights what matters most
Makes insights obvious at a glance

This means:

Choosing the right visuals (not just the fancy ones)
Using layout and hierarchy to guide the viewer’s eye
Limiting clutter
Using consistent formatting and colors (Best advisable to use colors relating to the type of dataset you have, e.g. In an agricultural dataset, you can use green to represent nature and maybe a touch of brown)

Instead of asking users to search for insights, great dashboards present them. For example:

A KPI card for Total Flight Trips
A trend line showing growth in flight safety over time
A bar chart ranking the top causes of flight accidents
A slicer to explore by region or cause

The goal isn’t to impress, but to inform and facilitate great business decision-making.

What Great Analysts Do Differently

The best analysts don’t stop at insights. They go one step further and translate them into recommendations, not just Flight safety was increased in Region B, but Flight safety improved in Region B, with major accidents decreasing by 78% after targeted safety measures were implemented based on identified root causes. This suggests the measures were effective. We should review how they were implemented and consider replicating the approach in other regions. This is where Power BI becomes a decision engine, not just a reporting tool. Here’s an example of action-oriented analysis:

Suppose an airline recorded 12,000 flights last year. After cleaning and modeling the data:

•You discover that 62% of delays happen during peak weather months.
•45% of major incidents are linked to maintenance scheduling gaps.

Instead of simply reporting these numbers, the recommendation becomes:

“Reallocate maintenance checks before peak weather months and reinforce crew training during high-risk periods.”

NOTE - Insight without action is just information. Action is what creates value.

Common Power BI Mistakes (and How to Avoid Them)

Making mistakes while working with Power BI — or any tool — is part of the learning process. Even experienced analysts make mistakes. Mistakes are part of the learning process. What matters is identifying them early and improving from them. Some of the most common include:

Building dashboards before understanding the business problem
- Always start with the question, not the visuals.
Overloading dashboards with too many charts
- Fewer visuals = clearer message.
Writing complex DAX that no one understands
- Keep formulas readable and documented.
Ignoring performance and refresh issues
- Optimize models and ensure reliable data updates.
Designing for yourself instead of the user
- Always think about who will use the dashboard and how, assuming they are not tech-savvy.
Not using a star schema.
- Poor model design can significantly reduce performance. Always aim for a clean fact table connected to dimension tables.

The Skills That Separate Good Analysts from Great Ones

Power BI is a technical tool, but great analysis is a blend of technical and human skills. Great analysts combine:

Power Query + DAX + Data Modeling
Business thinking
Communication and storytelling

They understand that:

Data is about people
Dashboards are about decisions
And analytics is about impact

Pros and Cons of Power BI

Just like every other software you can use out there, Power BI has its own pros and cons.

      1. Pros

Cost-Effective - Offers a free, functional desktop version, with affordable Pro licensing compared to competitors.
Microsoft Ecosystem Integration - Seamlessly connects with Excel, Azure, SQL Server, and Office 365.
Powerful Visualization & Data Handling - Features a wide range of interactive, custom visual tools and strong data modeling capabilities.
Constant Updates - Microsoft frequently updates the platform with new, AI-driven features.
Large Community Support - Extensive online resources, forums, and documentation are available.
```
   2. Cons
```
Steep Learning Curve - While easy for basic tasks, mastering DAX (Data Analysis Expressions) and complex data modeling requires significant technical expertise.
Performance Issues - Can become slow when processing, loading, or refreshing large or complex datasets.
Limited Customization - Flexibility for customizing visuals can be restrictive compared to tools like Tableau.
Dependency on Windows/Cloud - Primarily designed for Windows, with limited or no native, full-featured editing capabilities on other operating systems.
Licensing Complexity - The licensing structure can be confusing, and, for some, the cost of scaling (Premium) is high.

Conclusion

Finally! We now have a clear understanding of the Power BI analysis workflow. The workflow is structured and logical — and with consistent practice, it becomes second nature. Platforms like Kaggle provide high-quality practice datasets to sharpen your skills.

The analyst’s workflow can be summarized in three powerful steps:
Load -> Clean -> Model -> Calculate -> Communicate

Power BI supports every stage of the modern analytical workflow:

Power Query cleans the chaos
Data modeling creates structure
DAX builds intelligence
Dashboards communicate insight

Tools alone don’t create impact — analysts do.
The real value lies not in reporting what happened, but in guiding what should happen next.

ALL THE BEST IN YOUR POWER BI EXPLORATION

Getting Started with NotebookLM: Your Personalized AI Research Assistant (2025 Edition)

Wed, 24 Dec 2025 20:27:49 +0000

In a world drowning in information, the challenge isn't finding data—it’s synthesizing it. Enter Google NotebookLM. Unlike standard AI chatbots that pull from the vast (and sometimes unreliable) internet, NotebookLM is "grounded" in the sources you provide.

Whether you’re a student tackling a thesis, a professional analyzing market reports, or a creator organizing a podcast, here is how to master NotebookLM in 2025.

What is NotebookLM?

NotebookLM is an AI-powered research and note-taking tool that uses Gemini 2.5 Pro to understand your specific documents. Its magic lies in its "Source-Grounded" nature: it only knows what you tell it, drastically reducing "hallucinations" and providing clickable citations for every claim it makes.

Step 1: Create Your First Notebook

Go to the Site: Visit notebooklm.google.
Start New: Click the "New Notebook" button. Think of a Notebook as a dedicated project folder (e.g., "History 101" or "Q4 Marketing Strategy").
Add Your Sources: You can upload a wide variety of formats:
- Documents: PDFs, Google Docs, Slides, and Text files.
- Web: Paste URLs or link to YouTube videos (it will analyze the transcript!).
- Audio: Upload MP3s or lecture recordings.

Step 2: Meet Your "Studio" (The Power Tools)

Once your sources are uploaded, the Studio panel on the right is where the transformation happens. In 2025, NotebookLM added several heavy-hitting features:

Audio Overviews (The "Podcast" Mode): With one click, two AI hosts will have a deep-dive conversation about your sources. In the latest update, you can even click "Join the Conversation" to ask the hosts questions in real-time.
Video Overviews: Using the Nano Banana visual model, NotebookLM can now turn your text sources into narrated slideshow videos—perfect for quick briefings.
Mind Maps & Timelines: Automatically visualize how different concepts in your documents connect or see a chronological layout of events across multiple sources.

Step 3: Interacting with Your Data

The center of the screen is your Chat Window. This isn't just for summaries; it’s for deep interrogation.

Ask Specific Questions: "Based on these 5 PDFs, what are the three main risks of this project?"
Check Citations: Every answer will have small numbered badges. Click them to see exactly which page and paragraph the AI used to find that fact.
Save Notes: If the AI gives a great answer, click "Save to Note." Your notes live in the notebook alongside your sources, acting as a "living" draft of your final project.

Why 2025 is the Year of NotebookLM

Feature	Why It Matters
Deep Research Mode	It can now scan the web for verified sources to supplement your own files.
Increased Limits	Free users can now manage 50 sources per notebook; Pro users get up to 300.
Learning Guides	It can generate quizzes and flashcards automatically to help you study.
Privacy First	Google does not use your notebook data to train its global AI models.

Pro Tips for Success

Source Management: If you have too much data, use the checkboxes to "mute" specific sources. This forces the AI to focus only on the files you want for a specific question.
The "Gap Hunter" Prompt: Ask the AI, "What is missing from these sources that I should look for elsewhere?" It’s a brilliant way to find weaknesses in your research.
Audio Customization: You can now prompt the Audio Overview hosts to focus on a specific tone (e.g., "Make this sound like a technical debate").
*

NotebookLM is a new AI tool focused on source-grounded cognition, meaning it reasons only within the uploaded sources and doesn't improvise. This makes it auditable, private, and reliable for high-stakes work.
Using NotebookLM effectively requires careful "corpus architecture," focusing on curating and organizing the information uploaded, rather than just prompting. This involves designing the model's world through thoughtful source selection.
NotebookLM enables advanced workflows like legal research, creative continuity, business intelligence, and UX research. It represents a shift in AI literacy towards understanding corpus design and epistemic reasoning.

notebookLM should not be looked at as a typical LLM chatbot. Since we curate the dataset, at max, the hallucinations will be in the dataset. That’s a much more preferred output than LLM chat bots which could hallucinate wildly.

https://medium.com/@stunspot/everyone-is-wrong-about-notebooklm-802770aa12f7

https://www.linkedin.com/posts/theanishajain_how-to-get-a-job-thanks-to-ai-interview-activity-7409899270964965376-GcbI

https://www.geeky-gadgets.com/google-notebooklm-update/

https://www.linkedin.com/posts/axellemalek_news-notebooklm-now-creates-infographics-ugcPost-7414595876913987584-ZDNV?utm_medium=ios_app&rcm=ACoAABzB85UB8iZMlY6hoj9K3g7MfcRKsCZOvqw&utm_source=social_share_send&utm_campaign=copy_link

https://www.anthropic.com/research/AI-assistance-coding-skills

it isn’t a chatbot. It’s the first mainstream tool that rewires how humans interact with knowledge. in finding job/work it can also help check the main blog
https://notebooklm.google/

Let’s stay connected:

Instagram: https://www.instagram.com/angular_development/

Facebook: https://m.facebook.com/learnangular2plus/

Threads: https://www.threads.net/@angular_development

Medium: https://medium.com/@eraoftech

coderlegion: https://coderlegion.com/user/Sunny

Quora: https://neweraofcoding.quora.com/

YouTube: https://www.youtube.com/@neweraofcoding

LinkedIn: https://www.linkedin.com/company/infowebtech/

Hashnode: https://neweraofcoding.hashnode.dev/

GitHub: https://github.com/angulardevelopment/ | sunny7899

BlueSky: https://bsky.app/profile/neweraofcoding.bsky.social

Substack Newsletter: https://codeforweb.substack.com/

Pinterest: https://in.pinterest.com/tech_nerd_life/

dev.to: https://dev.to/sunny7899

Looking for web dev trainings: https://beginner-to-pro-training.vercel.app/

Software development services: https://infowebtechnologies.vercel.app/

Contribution to the web development community: https://code-for-next-generation.vercel.app/

Book a session: https://topmate.io/softwaredev

Telegram Channel: https://t.me/neweraofcoding

Thank you for being a part of the community. Happy coding!

Google Tag Manager GTM Setup Verification Guide

Sun, 10 Aug 2025 19:32:11 +0000

GTM Setup Verification Guide

Method 1: GTM Preview Mode (Most Comprehensive)

Step-by-Step Instructions:

Open GTM Console
- Go to tagmanager.google.com
- Select your container: GTM-XXXXXXX
Enable Preview Mode
- Click the "Preview" button in the top-right corner
- GTM will generate a preview URL
Test Your Website
- Open the preview URL in a new tab
- Your website will load with GTM debug panel at the bottom
Verify Events
- The debug panel shows all events being fired
- You should see events like:
  - page_view
  - form_field_focus
  - button_click
  - scroll_depth
  - section_view
Test Interactions
- Fill out the form
- Click buttons
- Scroll through the page
- Navigate between sections
- Watch events appear in real-time

Method 2: Browser Developer Tools

Check GTM Container Loading:

Open Developer Tools (F12)
Go to Network Tab
Refresh the page
Look for GTM requests:
- googletagmanager.com/gtm.js
- googletagmanager.com/gtm.js?id=GTM-5XFLRN8P

Check dataLayer:

Open Console Tab
Type: window.dataLayer
Press Enter
You should see an array with events

Test Event Tracking:

// In browser console, test manually:
window.dataLayer.push({
    'event': 'test_event',
    'event_category': 'test',
    'event_action': 'verification'
});

Method 3: GTM Container Verification

Check Container Code:

Verify Head Code (in index.html):

<!-- Google Tag Manager -->
<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-5XFLRN8P');</script>
<!-- End Google Tag Manager -->

Verify Body Code (in index.html):

<!-- Google Tag Manager (noscript) -->
<noscript><iframe src="https://www.googletagmanager.com/ns.html?id=GTM-5XFLRN8P"
height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript>
<!-- End Google Tag Manager (noscript) -->

Method 4: Event-Specific Testing

Test Each Event Type:

Page View Event:
- Open website
- Check console for: GTM Event: page_view
Form Events:
- Click on form fields
- Submit the form
- Check for: form_field_focus, form_submission, form_success
Button Events:
- Click various buttons
- Check for: button_click, cta_button_click, demo_button_click
Navigation Events:
- Click navigation links
- Check for: navigation_click
Scroll Events:
- Scroll through the page
- Check for: scroll_depth, section_view

Method 5: GTM Container Status Check

In GTM Console:

Container Status:
- Should show "Published" status
- Check for any errors in container
Tags Configuration:
- Verify tags are set up to trigger on your events
- Check tag firing rules
Triggers:
- Ensure triggers are configured for your events
- Test trigger conditions
Variables:
- Verify data layer variables are set up
- Check variable configurations

Method 6: Real-Time Testing

Using Google Analytics (if connected):

Open Google Analytics
Go to Real-Time > Events
Interact with your website
Watch events appear in real-time

Using GTM Real-Time:

In GTM Console
Go to Preview Mode
Interact with website
Watch events in debug panel

Common Issues & Solutions

Issue 1: GTM Not Loading

Symptoms: No GTM requests in Network tab
Solutions:

Check container ID is correct
Verify GTM code is in <head> section
Check for JavaScript errors

Issue 2: Events Not Firing

Symptoms: No events in dataLayer
Solutions:

Check JavaScript console for errors
Verify trackEvent function is working
Test with manual dataLayer.push()

Issue 3: Events Firing but Not Reaching GTM

Symptoms: Events in dataLayer but not in GTM
Solutions:

Check GTM container is published
Verify trigger configurations
Test in preview mode

Issue 4: Duplicate Events

Symptoms: Same event firing multiple times
Solutions:

Check for duplicate event listeners
Verify event tracking logic
Use event deduplication in GTM

✅ Verification Checklist

[ ] GTM container loads without errors
[ ] dataLayer is accessible in console
[ ] Page view event fires on load
[ ] Form events fire on interaction
[ ] Button click events fire
[ ] Scroll depth events fire
[ ] Navigation events fire
[ ] Events appear in GTM preview mode
[ ] No JavaScript errors in console
[ ] GTM container is published

️ Debugging Commands

Console Commands for Testing:

// Check if GTM is loaded
console.log('GTM Loaded:', typeof window.dataLayer !== 'undefined');

// Check dataLayer contents
console.log('DataLayer:', window.dataLayer);

// Manually trigger an event
window.dataLayer.push({
    'event': 'manual_test',
    'event_category': 'debug',
    'event_action': 'console_test'
});

// Check GTM container ID
console.log('GTM ID:', 'GTM-5XFLRN8P');

// Test trackEvent function
if (typeof trackEvent === 'function') {
    trackEvent('test_event', {test: true});
}

Expected Events in GTM

When testing, you should see these events:

Page Load:
- page_view
Form Interactions:
- form_field_focus
- form_field_blur
- form_submission
- form_success
Button Clicks:
- button_click
- cta_button_click
- demo_button_click
Navigation:
- navigation_click
User Engagement:
- scroll_depth
- section_view
- user_engagement
Carousel:
- carousel_navigation
External Links:
- external_link_click

Next Steps After Verification

Set up GTM Triggers for each event
Configure Tags (Google Analytics, Facebook Pixel, etc.)
Test in Production environment
Monitor Real-Time Data
Set up Conversion Tracking
Configure Enhanced Ecommerce (if applicable)

Full-Stack vs. Data Science: Which Career Path Scales Better in 2025

Fri, 08 Aug 2025 08:06:57 +0000

In 2025, the tech job market is shifting faster than ever. AI is rewriting job descriptions, remote work is the norm, and companies are hiring globally. If you’re at a career crossroads, two roles often come up: Full-Stack Developer and Data Scientist.

Both are lucrative, in-demand, and future-facing — but which one scales better for the next 5–10 years? Let’s break it down.

1. What Each Role Actually Does

Full-Stack Developer

Builds complete web applications — frontend (UI/UX) + backend (databases, APIs)
Works with frameworks like React, Angular, Node.js, Django
Handles everything from concept to deployment

Data Scientist

Extracts insights from data to guide business decisions
Works with tools like Python, R, SQL, TensorFlow
Builds models for predictions, recommendations, and automation

2. Salary & Growth in 2025

Role	Avg. Salary (Global)	Growth Outlook
Full-Stack Dev	\$75K – \$130K	Steady, demand in SaaS, fintech, e-commerce
Data Scientist	\$90K – \$150K	Strong, especially in AI-driven industries

Trend: In 2025, AI automation is boosting demand for AI-savvy Full-Stack Developers and business-focused Data Scientists.

3. Learning Curve & Entry Barrier

Full-Stack: Easier to get started — plenty of free resources, bootcamps, and junior roles. You can ship projects fast and build a portfolio quickly.
Data Science: Higher entry barrier — requires strong math, statistics, and domain knowledge. Beginners can start small with analytics, but ML-heavy roles take time to break into.

4. Industry Demand in 2025

Full-Stack is booming in:

SaaS products & startups
E-commerce & marketplaces
AI-powered business tools (frontends for LLMs, dashboards)

Data Science is booming in:

AI model fine-tuning
Predictive analytics in finance, healthcare
Recommendation systems for content & retail

5. Which Scales Better Long-Term?

If “scaling” means:

Easier to enter, quick job offers → Full-Stack wins
Higher specialization, bigger pay ceiling → Data Science wins
Global remote flexibility → Both win, but Full-Stack slightly edges ahead due to project-based contracts

6. The Hybrid Advantage

The real winner? Being both.

A Full-Stack Developer who understands data and AI can build end-to-end intelligent products.
A Data Scientist with frontend/backend skills can deploy models as live apps without relying on engineers.

Final Takeaway

In 2025, both career paths scale — but in different ways:

Full-Stack scales in breadth: faster entry, wider range of industries, more freelance/remote opportunities.
Data Science scales in depth: higher pay at senior levels, niche expertise in AI-driven sectors.

If you’re deciding today, think about your strengths:

Love building and shipping apps fast? Go Full-Stack.
Love analyzing and predicting with data? Go Data Science.
Love both? Congratulations — you’re building a future-proof career.

Repohistory

Tue, 05 Aug 2025 11:50:02 +0000

As a maintainer of a few open-source projects, I’ve always wanted to better understand the traffic sources and trends for my repos. Unfortunately, GitHub’s built-in analytics only show limited data from the past 14 days, which doesn’t provide much insight.

That’s why I built Repohistory, a better GitHub repo analytics platform. It automatically fetches and stores your traffic data every day, so you’re no longer limited to just 14 days. The dashboard shows you:

Daily star growth
Total views & clones over time
Top referral websites
Most-viewed pages in your repo

So if you have any public repos on GitHub, Repohistory can give you a much clearer picture of your traffic trends.

Try it here: https://repohistory.com

Coder Legion - Recent posts tagged analytics

What Is a Good Conversion Rate? (And Why the Average Can Fool You)

What is a conversion, exactly?

How to calculate your conversion rate

So what is a good conversion rate?

Split the rate into steps

Measure what counts as a win

Careful: a higher conversion rate is not always better

Know what one conversion is worth

8 ways to raise your conversion rate

Nadia’s new conversion rate

Find your weakest conversion step

Good conversion rate FAQ

What is a good conversion rate?

How do I calculate my conversion rate?

Is a 2% conversion rate good?

Why is my conversion rate low?

Should I trust average conversion rate benchmarks?

LifeOps Project (Part 6): 360° Analytics Dashboard with Multi-Dimensional Filtering, Recharts and Co

1. Architecture Decision: External BI (Grafana / Metabase) vs. Native React Engine (ADR-013) ⚖️

Data Flow Architecture

2. Multi-Dimensional Cascading Filters & Period-over-Period Deltas ⏱️📊

A. Timeframe Resolution

B. Invariant INV-8: Safe Percentage Delta Calculation (Δ%)

3. The Visual Suite with Recharts: Contextual KPIs, Time-Series & Donut Charts 📈🍩

4. 16-Week Consistency Daily Heatmap (Strava / GitHub Style) 🔥🗓️

5. Overcoming the Free-Tier Cloud UX Challenge: Cold-Start Mitigation ⚡🛡️

Layer 1: Silent Pre-Warming (wakeUpServer)

Layer 2: User-Scoped Stale-While-Revalidate (SWR) Local Cache

Layer 3: Foreground Synchronization Banner and Skeletons

6. Conclusions & Links 🚀

What Is a Good Bounce Rate? Ranges by Page Type and When to Worry

What is a bounce, exactly?

Good bounce rate ranges by page type

When a high bounce rate is fine

When a high bounce rate is a problem

How to find out why people bounce

7 ways to lower a bad bounce rate

A good bounce rate: the bottom line

Good bounce rate FAQ

What is a good bounce rate?

Is a 70% bounce rate bad?

Why did my bounce rate drop in GA4?

How do I lower my bounce rate?

I let every AI crawler in. A month later I cannot tell you how many people read me.

Why does a pageview count not tell you how many people read you?

Is letting AI crawlers in actually worth it?

How do you count crawlers without tracking people?

What NOT to keep, which is the hard part

What does counting cost?

The line that nearly made me publish a lie

What I still do not know

What 1.23M Edge Requests Taught Us About AI Crawlers (and Our Own Analytics)

The split

Selected AI operators (requests in 90 days)

robots.txt compliance

Status codes

Don't mix units

Heatmap Empty After Installing a Cache Plugin? 3 Checks in 60 Seconds

Telemetry: Shared Analytics and Crash Reporting in Kotlin Multiplatform

What I had before

The interface lives in commonMain

Android: the easy side

iOS: the Swift bridge

Two other ways to bring the SDK in

Kotlin exceptions on iOS are not Kotlin exceptions

Where the calls go

Gotchas

Wrapping up

Testing on production without polluting your data (and the day my tests voted 8 times)

1. Nothing reaches Google Analytics

2. The real API, with a tag

3. Delete it when you're done

4. The table that had no tag

What I'd tell myself a month ago

Unstructured Data Analytics Tools Unlock Hidden Business Insights

Introduction

Understanding Unstructured Data

How Unstructured Data Analytics Tools Create Business Value

The Role of AI and Machine Learning

Layer 1: Silent Pre-Warming (`wakeUpServer`)