DEV Community: Emirhan Güven

How we measured Telegram channel reach across 3.2M public channels (and why the median, not the mean)

Emirhan Güven — Sat, 19 Sep 2026 01:04:06 +0000

Telegram prints a view counter on every public channel post. Put that next to the subscriber count and you get a number no other large platform hands you for free: what share of an audience actually sees a post. We computed it across a catalogue of 3,205,346 public channels and published the result as open data. This note is about how the measurement was built, where it is weak, and why the headline figure is a median.

The short version of the result: on channels with 1,000 to 5,000 subscribers the median post is seen by 31.4% of subscribers. Above 500,000 subscribers it is 3.3%.

The definition

For each channel:

reach = average views per post / subscribers

Then, for each size band, the median of that ratio across the channels in the band. That is the whole formula. A channel with 10,000 subscribers whose posts average 1,500 views has a reach of 15%.

Two implementation details matter more than the formula itself.

The ratio is computed from the two stored inputs, not from a precomputed engagement column. The crawler has its own engagement field, but it is still being backfilled, and reading it would make the score exist for some channels and not others with no visible reason. Dividing two columns that are always present is duller and always answers.

Channels under 1,000 subscribers are excluded. Below that floor a single forwarded post can put the ratio anywhere, so it is too noisy to rank. The API reports these as below_floor rather than scoring them zero. The same goes for groups (not_a_channel: Telegram publishes no per-post views for groups) and for channels the crawler has never seen a view count for (no_view_sample). None of those is an error, and none of them is silently folded into the statistics.

Why the median

The obvious summary is the mean. We did not publish it, for two reasons that pull in opposite directions.

The first is the tail above 1.0. A ratio above 1.0, more views per post than subscribers, is common on Telegram and is not proof of a real audience. Forwards, cross-posts and paid promotion all deliver views from people who are not on the subscriber list. In our scoring those channels get the verdict amplified, which says out loud that the reach is arriving from outside. A few channels several times above 1.0 move a band mean a long way and tell you nothing about the typical channel in that band. The median does not move.

The second is the tail at the bottom. Subscriber counts padded with bought or long-dead accounts push the ratio down. A band mean would be dragged by those as well, in the other direction, and the two distortions do not cancel in any way you can rely on.

The median is also what a benchmark needs. "Half of the channels this size do better than 6.0%" is a sentence you can act on: a 200,000-subscriber channel reaching 12% is doing twice as well as its peers, and one at 2% deserves a closer look before you pay for a post. A mean gives you no such sentence.

Internally the median is one point of a 101-point percentile ladder per band. The public page shows the medians; the API exposes the ladders with their sample sizes and rebuild timestamps, so a percentile is never a number with an invisible population behind it.

Count everything where you can, sample where you cannot

Five bands, filled two different ways.

Band	Median reach	Channels measured	Basis
1k-5k	31.4%	7,179	sample
5k-20k	15.8%	2,750	sample
20k-100k	9.1%	1,201	sample
100k-500k	6.0%	8,380	every channel
500k+	3.3%	1,211	every channel

The two large bands are exact because they are small: 8,380 and 1,211 channels is nothing to compute over. The small bands are enormous (the 1k to 10k range alone projects to roughly 338,000 channels), so their ladders are built from a TABLESAMPLE of the band. The shape is sound; a percentile from a sampled band is an estimate, and the exact: false flag on each band says so. In the CSV the same flag is the basis column.

One consequence worth knowing. The size distribution comes from a separate sample of 14,431 channels with a known subscriber count, and it projects roughly 7,900 channels above 100,000 subscribers. The exact reach tables hold 9,591 (8,380 plus 1,211). The projection rests on a few dozen sampled rows in a band that is about a quarter of one percent of the network; a miss of about 20% is what sampling error looks like at that rarity. When an exact count and a projection disagree, trust the exact count.

What we left out, and why

Three catalogue fields did not make the report.

Category. Most channels carry no category label at all. Of 15,240 sampled channels, 719 had one. Those counts describe who bothers to label a channel, not Telegram. They are in the JSON with that caveat attached; they are not on the page.

Country. The country facet came back empty on the same sampling pass: not one sampled channel carried a value. There was nothing to publish.

Languages beyond the top four. Language is detected automatically from short channel descriptions. For Russian (27.0% of sampled channels), English (12.1%), Arabic (6.0%) and Persian (5.6%) the detector is reliable. Below that it starts confusing related languages, and the long tail ranks some languages in places nobody who has used Telegram would put them. So the page shows four, and the JSON keeps the full tail with its raw sample counts so you can judge the noise yourself.

The rule we ended up with: a populated field is a claim, not a measurement. Publish the ones you can defend, ship the rest as raw rows.

The limits that stay

Telegram's view counter counts every view of a post, including views through forwards and web previews by people who are not subscribers. Reach here can therefore overstate the share of subscribers who saw a post, most of all on channels whose posts travel. Subscriber counts inflated by inactive or bought accounts pull the other way. Bands below 100,000 subscribers are sample estimates. Everything under 1,000 subscribers is outside the reach figures, and by count that is 85.7% of the catalogue.

One script, three outputs

The last decision was the boring one. The two API responses (/insights/telegram/reach-bands and /directory/telegram/facets, captured on 11 September 2026) sit in the repo as snapshots, and one Python script turns them into the TypeScript constants the page renders, the CSV and the JSON. The page cannot drift from the downloads because none of the numbers is typed by hand.

The data

Report and tables: https://pinlyx.com/research/telegram-channel-reach-2026
CSV: https://pinlyx.com/data/telegram-channel-reach-2026.csv
JSON, including the category rows and the full language tail: https://pinlyx.com/data/telegram-channel-reach-2026.json

CC BY 4.0. Use it, quote it, republish it; the only ask is attribution.

Disclosure: I work on Pinlyx, the CRM whose catalogue these figures come from.

If you have measured the same ratio on another platform that exposes per-post views, I would like to know whether the tenfold fall from small channels to large ones holds there too.

Google crawled 230 pages of my site and indexed 2. Here is how I diagnosed it.

Emirhan Güven — Fri, 04 Sep 2026 15:52:13 +0000

My marketing site has 230 URLs in its sitemaps. Google has indexed 2 of them.

Not "pending". Not "blocked". Crawled, fetched successfully, canonical accepted, and then declined. This post is the diagnostic path I took, the two measurement mistakes I made along the way, and the Search Console API calls that finally produced a straight answer.

The setup

The site is a Vite + React SPA prerendered at build time by Puppeteer. Every route ships as a static HTML file with the content already in the markup, served by nginx. Not SSR, but for a crawler it is indistinguishable: the body arrives full.

The obvious hypotheses, in the order everyone tries them:

Google cannot render the JavaScript.
robots.txt is blocking something.
Canonicals point somewhere else.
The pages are thin or duplicated.
There is a manual action.

All five were wrong. Here is how each died.

Killing the easy hypotheses

Fetch the page as Googlebot and check the markup directly:

curl -sS -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://example.com/ -o home.html

grep -o '<title>[^<]*</title>' home.html
grep -o '<link rel="canonical"[^>]*>' home.html
grep -c '<h1' home.html

381 KB of HTML, one <h1>, correct canonical, index, follow. Rendering was never the problem.

For internal links, count real anchors rather than trusting a framework's router:

hrefs = re.findall(r'<a\s[^>]*href="([^"]+)"', html)
internal = [h for h in hrefs if h.startswith('/')]
print(len(set(internal)), html.count('nofollow'))
# 84 unique internal links, 0 nofollow

That matters because a React app that navigates with onClick handlers instead of <a href> is invisible to a crawler's link graph. This one was fine.

The Search Console API is the only source of truth

Everything above tells you what you serve. It says nothing about what Google decided. For that there are exactly two useful endpoints.

URL Inspection — per-URL verdict, up to 2000 calls/day:

from googleapiclient.discovery import build

service = build('searchconsole', 'v1', credentials=creds)
result = service.urlInspection().index().inspect(body={
    'inspectionUrl': 'https://example.com/pricing',
    'siteUrl': 'sc-domain:example.com',
}).execute()

status = result['inspectionResult']['indexStatusResult']
print(status['verdict'], '|', status['coverageState'])
print(status['robotsTxtState'], status['pageFetchState'], status['lastCrawlTime'])

Run it over a representative sample rather than one URL. Mine came back like this:

/                      PASS    | Submitted and indexed
/pricing               NEUTRAL | Crawled - currently not indexed
/features              NEUTRAL | Crawled - currently not indexed
/telegram-crm          NEUTRAL | Crawled - currently not indexed
/compare/x-vs-y        NEUTRAL | Crawled - currently not indexed
/guides/some-guide     NEUTRAL | Crawled - currently not indexed

Every one of them: robotsTxtState: ALLOWED, pageFetchState: SUCCESSFUL, lastCrawlTime within the last two weeks, googleCanonical matching userCanonical.

That combination is unambiguous. Google arrived, fetched a 200, parsed the page, agreed with my canonical, and chose not to index. There is no technical defect to fix, because nothing failed.

The aggregate view confirmed it: 2 indexed, 185 not indexed — 99 "Discovered, currently not indexed" and 86 "Crawled, currently not indexed".

Two measurement mistakes worth stealing

1. `quick_ratio` will tell you your pages are duplicates when they are not

Template-generated pages (/compare/a-vs-b, /use-cases/industry) are the obvious suspects for thin content. So I measured similarity:

import difflib
ratio = difflib.SequenceMatcher(None, page_a, page_b).quick_ratio()
# 95.9%, 90.9%, 88.5% ...

Damning, apparently. Except quick_ratio() compares character frequency multisets, not sequences. Two unrelated English documents of similar length score high on it by construction. It is a cheap upper bound designed to skip expensive comparisons, not a similarity metric.

The honest measurement is to strip the shared chrome and count what survives:

from collections import Counter

# how many pages does each line of text appear on?
counts = Counter()
for lines in docs.values():
    for line in set(lines):
        counts[line] += 1

for url, lines in docs.items():
    unique = [l for l in lines if counts[l] == 1]
    total_w  = sum(len(l.split()) for l in lines)
    unique_w = sum(len(l.split()) for l in unique)
    print(url, f"{unique_w}/{total_w} = {unique_w*100//total_w}% unique")

Result: 90-95% unique per page, 1400-1950 words of it, with only ~35 words of shared boilerplate (nav, CTA strip, footer). The pages were not the problem. Had I stopped at quick_ratio I would have spent a week rewriting content that was already fine.

2. `site:` in a search box is not an index count

num=100 no longer works on Google. If you count results on the first page you are counting ten. Paginate with start= and stop when a page returns fewer than a full set, or just read the Page Indexing report, which is authoritative.

What the answer actually was

With the technical hypotheses dead, one report explained everything:

External links: Total 10   (3 domains)
Internal links: Total 0

Ten inbound links from three domains, all to the homepage. Meanwhile a backlink tool reported 197 links — but more than half came from a single PBN spam network hammering one keyword-stuffed anchor. Google had simply not counted them. The tool's number was noise; Search Console's was the signal.

So: a site with real content, clean markup, correct canonicals, valid sitemaps, no manual action, and effectively zero independent references, publishing 230 pages into one of the most saturated categories on the web.

"Crawled, currently not indexed" is not a bug report. It is a verdict. Google read the pages and decided the index did not need them. More crawl budget does not fix that, and neither does resubmitting a sitemap — I have two months of flat data to prove it.

The part that generalises

If pageFetchState is SUCCESSFUL and robotsTxtState is ALLOWED, stop debugging your stack. The answer is not in your code.
Check the Links report before rewriting content. Zero external links explains more indexing problems than any rendering bug.
Backlink tools and Search Console disagree, and for "does Google count this link", Search Console wins.
Verify a claimed fix against production before repeating it. Three broken URLs I was still citing from a month-old crawl had already been redirected; I only found out because I re-checked with curl instead of trusting my notes.

The uncomfortable conclusion is that for a new domain in a crowded category, indexing is downstream of being referenced by someone other than yourself. That is a distribution problem wearing a technical costume.

I work on Pinlyx, an omnichannel CRM (it was called CRM Solid when this was written). The numbers above are from its marketing site, which is a live and ongoing example of the problem.

Four traps in querying 1.79M Overture Maps records with DuckDB

Emirhan Güven — Tue, 01 Sep 2026 10:18:27 +0000

We needed a business directory for Turkey inside our CRM, so we went to
Overture Maps places: open, CDLA-Permissive, no API key,
no quota, ~1.8M Turkish records sitting in public GeoParquet on S3.

Reading it turned out to be the easy part. Here are the four things that actually cost us
time, and the numbers that came out the other end.

1. A join against remote parquet does not stream

The obvious query is one statement: read the places theme, read the divisions theme, keep
the rows whose point falls inside a Turkish province.

-- Do not do this against S3.
SELECT p.*
FROM read_parquet('s3://.../theme=places/*/*', hive_partitioning=1) p
JOIN regions r ON ST_Within(p.geometry, r.geom)
WHERE r.country = 'TR';

DuckDB materialises that join before it emits a single row. Ours sat at 2.5 GB of RAM
and produced nothing after fifteen minutes, with no way to tell whether it was making
progress.

The fix is boring and works: two stages. Stage one pulls the country down with a plain
bounding box and zero spatial work.

CREATE TEMP TABLE places_tr AS
SELECT id,
       names.primary        AS name,
       categories.primary   AS category,
       websites[1]          AS website,
       bbox.ymin            AS lat,
       bbox.xmin            AS lon,
       geometry             AS geom
FROM read_parquet('s3://.../theme=places/*/*', hive_partitioning=1)
WHERE bbox.xmin BETWEEN 25.5 AND 45.0
  AND bbox.ymin BETWEEN 35.7 AND 42.3
  AND names.primary IS NOT NULL
  AND (operating_status IS NULL OR operating_status <> 'closed');

A rectangle over Turkey also sweeps in slivers of Greece, Bulgaria and Georgia. That is
fine, stage two throws them out. Stage two then loops province by province, so each join
touches one polygon and a few thousand candidate rows:

SELECT p.* FROM places_tr p, tr_regions r
WHERE r.region_name = 'İzmir' AND ST_Within(p.geom, r.geom);

Every step is bounded and you can watch it progress. Same result, and the whole run
finishes instead of hanging.

2. 81 provinces, 109 polygons

Turkey has 81 provinces. Overture's divisions theme hands you 109 region rows for the
country. My first reading was "duplicates": Adana, Antalya and Artvin each arrive twice, so
merge by name and move on. That works, but it hides the real reason, which is in the schema:
every coastal province has a second division_area row with class = 'maritime' for its
territorial waters (81 land + 28 maritime in release 2026-07-22.0; Antalya's maritime
polygon is larger than its land). If you loop over the raw rows you process those provinces
(and their companies) twice.

CREATE TEMP TABLE tr_regions AS
SELECT region_name, ST_Union_Agg(geom) AS geom
FROM (
  SELECT names.primary AS region_name, geometry AS geom
  FROM read_parquet('.../theme=divisions/*/*', hive_partitioning=1)
  WHERE country = 'TR' AND subtype = 'region' AND class = 'land'
    AND names.primary IS NOT NULL
)
GROUP BY region_name;

class = 'land' is the fix; the GROUP BY stays as a guard so downstream code can rely on
exactly one polygon per province name. One line, and it removes a whole class of
double-counting bugs.

3. The address field will not tell you the province

This is the one worth knowing before you plan anything. Overture's address region field
is null on roughly 92% of Turkish records, and inconsistent on the rest. There is no
salvaging it. Province has to be assigned geographically, from coordinates.

And it has to be a real point-in-polygon test, not a bounding box. Province bounding boxes
overlap heavily; picking the smallest containing box puts central İzmir in Manisa and
central Antalya in Burdur. We found that the entertaining way.

4. Lone surrogates will abort your bulk insert

Loading the results into Postgres with Npgsql's binary COPY, the batch died on real
company names. The cause: lone surrogates, half of an emoji pair, usually from a
truncated source record. Npgsql's UTF-8 encoder throws on those and takes the whole batch
with it.

Two details that cost us a second round trip:

Truncating a string to a column width can split a valid surrogate pair, so sanitising has to run after truncation, not before.
Null bytes need dropping outright; Postgres rejects them in text columns.

What it bought

Querying Overture's S3 parquet directly from a Turkish host: 277 seconds for a single
province. The same query against the local Postgres catalogue: 15 ms. That is the
difference between a feature and a batch job.

And then the actual finding

With 1,786,700 businesses loaded, we asked how many of them have a website. The field says
684,496, or 38.3%.

So we requested every one of those addresses. 413,777 answered. The rest time out,
refuse the connection, or sit on an expired domain.

The honest national figure is 23.2%: roughly one Turkish business in four can be
reached on the web at all. Meanwhile 542,323 businesses publish a phone number and no
website whatsoever.

The same gap shows up in the socials array, in the other direction: Overture has Facebook
on 95.3% of Turkish records but Instagram on only ~14k, an artefact of when the source
listings were assembled. Crawling the company websites we could reach found Instagram on
about 36% of them, taking the count to 232,928. Treat a populated field as a claim, not
a measurement.

The data is open

Everything above is published under CC BY 4.0, province and sector breakdowns included:

Report and tables: pinlyx.com/research/turkey-business-digital-report
CSV, JSON and the SQL that produces the figures: github.com/Pinlyx/turkey-business-digital-data
Archived with a DOI: 10.5281/zenodo.22217770

If you are working with Overture in another country, I would genuinely like to know
whether the region field is as empty there as it is here.