Methodology
Data tables · Onward reporting · Definitions · Gaps
This is the data half of the tg.pe transparency report: the full tables behind every summary figure, and how each one is defined. Two parts have pages of their own: the safety pipeline and RDAP bootstrap coverage.
It is written for security researchers, network operators, and internet-governance readers, and for anyone running a small service who wants to copy the parts that work. Where a figure is preliminary or the sample is small, the text says so rather than rounding it into a claim.
Measurement: domain age and RDAP coverage
Resolving the age of every destination's registrable domain, and recording which source answered, turns a routine safety check into a small measurement of where RDAP is actually deployed. That measurement, its per-ccTLD table, and the six limits it cannot be cited without now have a page of their own: RDAP bootstrap coverage. The cache TTLs a reimplementer needs are in definitions, and what the instrument still cannot answer is in the gaps list.
The safety pipeline
Every link is checked before it goes live, again in the background once the response is flushed, and again on later clicks. Each stage's data source, what it does on a hit, its fail mode, the reasoning behind the non-obvious choices, and the change history now have a page of their own: the safety pipeline. What the automation has caught, and the per-stage funnel that is still missing, are summarised there and listed in the gaps list.
Where links come from
Most links come from identified Telegram users via @tgpebot; the rest from the anonymous Web form and a few API integrations. The chart breaks the Web share down by submitter country (Cloudflare's CF-IPCountry at submission, so VPS/VPN endpoints in FI/NL/US/RU read as rented infrastructure, not the submitter's real location). Click a legend item to focus it.
Telegram dominates volume every year. Within Web, Taiwan led 2019 and 2022; from 2020 on, Russia dominates; legitimate users mixed with automated probes. The 2025 Web spike came overwhelmingly from RU/US automated submissions (sharp single-hour UTC peaks consistent with cron-driven bots); most appear to have been caught at the safety pipeline, though the per-stage catch rate is not yet quantified (see the funnel above).
By channel, and where removed abuse came from (charts)
Total submissions by channel (Web / Telegram / API), with unique submitters overlaid:
Of the links that were removed, where did the submitter sit? Telegram is deduplicated to distinct users so ban cascades don't inflate it; Web stays per-link.
The asymmetry the charts show is structural. Telegram carries more removed links than its lighter submission-time gates would suggest a problem with: because identified users face fewer front-door checks, more slips through at submission, but it is caught later, by external reports, the 7-day click-driven re-check, or manual review, and a single ban then clears that user's entire history. Web, by contrast, is filtered hard at the front door, so less reaches the point of removal. (The per-channel counts are read off the charts above.)
When links get shortened (submission-rhythm heatmaps)
Submissions over the last 104 weeks, day-of-week × hour-of-day in UTC, Web vs Telegram:
| 00 | 06 | 12 | 18 | |||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Sun | ||||||||||||||||||||||||
| Mon | ||||||||||||||||||||||||
| Tue | ||||||||||||||||||||||||
| Wed | ||||||||||||||||||||||||
| Thu | ||||||||||||||||||||||||
| Fri | ||||||||||||||||||||||||
| Sat |
| 00 | 06 | 12 | 18 | |||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Sun | ||||||||||||||||||||||||
| Mon | ||||||||||||||||||||||||
| Tue | ||||||||||||||||||||||||
| Wed | ||||||||||||||||||||||||
| Thu | ||||||||||||||||||||||||
| Fri | ||||||||||||||||||||||||
| Sat |
Web shows sharp isolated peaks at exact UTC hours, the signature of cron-scheduled bots. Telegram's heat is diffuse across the week, human use across many timezones. That asymmetry is the reason Web gets stricter rate limits and new-domain thresholds than Telegram. The heatmaps confirm that split rather than driving it.
What people shorten
Top destination hosts among active links (self-referential tg.pe links excluded):
| Host | Active links |
|---|---|
| t.me | 2,648 |
| telegra.ph | 1,736 |
| drive.google.com | 1,225 |
| facebook.com | 1,031 |
| hinet.net | 1,016 |
| docs.google.com | 908 |
| elnacional.cat | 557 |
| youtube.com | 546 |
Mostly messaging-app deep links, cloud-file sharing, and Taiwan-local content.
Click distribution (the long tail)
Click counting started in April 2026 (the SQLite→MySQL migration), so earlier clicks aren't counted. Among links clicked since then, split by submission channel (API excluded):
| Click bucket | Web | Telegram |
|---|---|---|
| 1 – 10 clicks | 441 | 1,698 |
| 11 – 100 clicks | 83 | 129 |
| Over 100 clicks | 24 | 11 |
Removal timing & re-check coverage
Removal authority comes from the public Terms every submitter accepts. One Telegram ban soft-deletes every link that user ever created. Re-check is click-driven: a click on a link not checked in the last 7 days triggers a fresh Safe Browsing call. The verified figure is a ~4-hour median from external report to removal; that median describes active response, not all removals, because backlog cleanup and ban-cascade sweeps are much older and would otherwise pull it out of shape.
Time from creation to removal
How old each link was when it came down. The top group is active response to fresh abuse; the bottom group is backlog cleanup and ban-cascade sweeps, whose timings reflect when the operator audited, not when the abuse was first detected.
| URL age at removal | Removals | % |
|---|---|---|
| Active response | ||
| Under 1 hour | 62 | 7.3% |
| 1 – 24 hours | 220 | 26.0% |
| 1 – 7 days | 201 | 23.8% |
| Backlog cleanup & ban cascade | ||
| 7 days – 1 year | 297 | 35.1% |
| Over 1 year | 65 | 7.7% |
Excludes 1,296 links soft-deleted in a single batch on 2025-01-06 21:24, a one-time inventory cleanup whose synthetic timestamps would distort the distribution.
Re-check coverage
Live Google Safe Browsing calls fired against existing short links since the April 2026 integration:
| Window | Live re-checks |
|---|---|
| Last 7 days | 679 |
| Last 30 days | 2,644 |
| All-time (since integration) | 3,104 |
The other ~25,000 active links pre-date the Safe Browsing integration; their last_safety_check_at was backfilled to creation date at the April 2026 migration. Their first live check fires on the next click. Most never get one (see the long tail under Click distribution), which is by design: idle URLs shouldn't burn API quota until somebody is about to be exposed.
Abuse reports: reporters & yearly volume
External reports come from national CERTs, anti-fraud vendors, and ordinary recipients. Over the service's life the top three sources (CIRCL, the US IRS, and Netcraft) are ~76% of volume; the long tail confirms tg.pe sits on multiple watchlists. The narrative cases, including the worst-category one, are in the transparency report.
Yearly volume and response time
Reports = external incoming. Links reported = distinct tg.pe/{code} short links named in those reports. Response time = median time from first report to removal.
| Year | Reports | Links reported | Response time | Notes |
|---|---|---|---|---|
| 2026 (YTD) | 4 | 2 | 2.4 h | Includes the parcel-delivery scam reported by an ordinary user (the featured case). |
| 2025 | 18 | 3 | 4.6 h | Q4 spike (mail-server-side incident, not tg.pe-shortened content); same-day handling. |
| 2024 | 8 | 3 | 5.2 h | Mostly Netcraft; same-day handling. |
| 2023 | 39 | 7 | 2.9 h | Volume dropped; remaining reports handled within hours. |
| 2022 | 207 | 26 | 5.1 h | IRS impersonation + CIRCL bulk wave, the largest sustained external pressure to date. |
| 2021 | 25 | 37 | 2.5 h | First-line defences built (see timeline). Many reports came as multi-code batches. |
| 2020 | 12 | 2 | 4.8 h | First reports arrived (Cloudflare / Netcraft / DigitalOcean). Tiny volume. |
The 2022 row is the most meaningful: even at peak external pressure, median report-to-removal held ~5.1 hours.
Onward reporting: channels and case detail
When the operator confirms a removed destination is malicious and classifies it, the indicator is reported onward to the abuse-handling community so the underlying page can be acted on wherever else it is reaching people. Each report goes only to the channels that fit it; a mis-routed report burns reporter reputation, which is the scarce resource here. Counting only successful sends: 7 via API and 20 assisted-manual.
MISP events carry machine-readable taxonomy tags: TLP:GREEN, source:tg.pe, an incident classification, and the destination's registration age, the same registration-age datum the new-domain check resolves (the measurement section); when a reported destination is later taken down, the event is updated in place with the outcome and timeline. CSAM is never sent to these phishing/malware feeds; it is referred out of band to NCMEC, the IWF, or law enforcement.
| Channel | Method | Reports |
|---|---|---|
| Netcraft | manual | 5 |
| Google Safe Browsing | manual | 4 |
| abuse.ch ThreatFox | API | 3 |
| Microsoft SmartScreen | manual | 3 |
| NetBeacon (→ registrar) | manual | 3 |
| CIRCL MISP | API | 3 |
| phish.report | API + manual | 2 |
| .TOP registry | manual | 1 |
| Cloudflare | manual | 1 |
| REA Group (impersonated brand) | manual | 1 |
| OMEGATECH (origin host) | manual | 1 |
All were phishing or scam; no malware or CSAM has been routed to these feeds.
13 August 2026, hour by hour
The case summarised on the transparency report, as logged. All times UTC.
| Time | Event |
|---|---|
| 02:12 | validationreq.top registered (registrar PDR Ltd.) |
| 03:29 | Link submitted to tg.pe; automated checks flag the hours-old destination and contain the link; evidence captured automatically |
| 05:57 | CIRCL MISP event published (event 508641) |
| 06:29 | Reports filed: registrar (via NetBeacon), .TOP registry, Cloudflare, Google Safe Browsing, Microsoft SmartScreen, Netcraft |
| 06:47 | Cloudflare URL-level block verified; sibling URLs on rotated paths still live |
| 09:46 | .TOP registry applies serverHold (ticket #1022402) |
| 09:59 | NS resolution verified dead network-wide |
The page itself showed nothing but a brand mock-up and a "Verification" button, with the payment-card form appearing only after a click, so an automated capture scored the page benign; it took operator review to spot the fraud behind the button. The impersonated brand's security team and the origin hosting provider were notified the same day, and the MISP event was updated afterwards with the takedown outcome and this timeline. The registrar comparison is one data point, not a pattern; registrar routing through a third-party intake can simply be slower.
An earlier loop, closed more slowly
On 25 May 2026 a tg.pe link to a Flipkart-impersonation phishing page on gauseva.life was removed and reported to five channels. On 2 June 2026 phish.report confirmed the domain suspended by its registrar (case case_fn4ae2bso6ps), eight days from removal to suspension, with an external reference the operator did not generate. Not every report closes: a cloaked affiliate smartlink reported to Netcraft came back "no threats found", because monetisation redirectors serve benign content to datacentre scanners. This is n=2 closed and n=1 not. It is not evidence that reports lead to takedowns, and nothing here should be read as "typically" or "usually". What fraction of onward reports end in a confirmed removal is not yet measured (see the gaps list).
Bans & domain lists
208 submitters are currently banned, all Telegram users; a ban soft-deletes every link that user ever created. No Web submitter has ever been individually banned; Web abuse is stopped upstream by the safety pipeline, and Web IPs are too mutable to ban usefully. The verified central figure is a median of 2 links before a ban.
Domain lists
| List | Count | Examples | Behaviour |
|---|---|---|---|
| Block list | 55 | Phishing landing pages, malware distribution sites | Refused on both Web and Telegram. |
| High-risk list | 370 | Other URL shorteners, free hosting platforms | Refused on Web only; identified Telegram users pass. |
Links before a ban
| Median (50th percentile) | 2 |
| 75th percentile | 3 |
| 95th percentile | 11 |
Methodology & definitions
- “Removed for safety / abuse” =
short_links.deleted_at IS NOT NULL, both automated re-check removals and manual operator removals. - “Banned submitters” = entries in
banned_users. - Country code =
CF-IPCountryat submission time (Web only); VPS/VPN endpoints read as rented infrastructure, not the submitter's residence. - Clicks are counted only since the April 2026 SQLite→MySQL migration; earlier clicks are not counted.
- Cache TTLs a reimplementer needs: a registration date is immutable, so it is cached 30 days; reputation is mutable, so it is cached 1 day.
This report is generated from a snapshot of the production MySQL database plus the operator's mail archive.
What's not in this report (yet)
| Not measured | Why it is absent | What would close it |
|---|---|---|
| Per-stage catch funnel | The rows exist in submission_rejects and malicious_detections, but no per-stage query is published, so the denominator for the 148 background tightenings is unknown. |
An integrator query carrying the total scan count, which is what turns the 148 into a rate and each stage's overlap into a number. At this n it must be clearly labelled as small. |
| Phished-brand attribution | The large majority of reports are phishing, but which brands are most often impersonated has not been tagged. | Per-message body analysis, in progress. |
| Closed-loop takedown rate § | Two outbound reports are confirmed all the way to suspension (one registrar, one registry serverHold) and one cloaked smartlink did not close. There is no denominator. |
Recording the outcome of every onward report, split between throwaway phishing registrations and cloaked monetisation redirectors. |
| Registrable-domain age at scale RDAP coverage | Legacy removals scrubbed the destination, so the usable sample is small. | Retaining the destination and its source-tagged registration date on every removal going forward, which would turn the two-population shape into a population statistic. |
| Per-lookup RDAP outcome RDAP coverage | resolveDomainAge() computes the source tag, but it is only persisted when a submission also trips the new-domain honeypot, and malicious_detections.source only ever carries virustotal. The outcome survives in a cache that overwrites itself and drops failures, not in a table, which is the wrong instrument for the job. |
Logging one row per age resolution, with the source, the TLD, and the miss cause. That would replace every disclosure under the coverage figure with a clean denominator. |
One correction to the record belongs with that last row: an earlier version of this report claimed the source tag recorded RDAP-hit versus pDNS-fallback per lookup. It does not.
If any of this is useful, for research, for policy work, or because you run a similar service and want to compare notes, the operator would rather share than keep it private: abuse@tg.pe.