DEV Community: Matvey

I Asked Instagram for NASA's 12 Newest Reels. Nine Belonged to Other Accounts

Matvey — Sun, 18 Oct 2026 13:13:38 +0000

I run a visa agency in Bali. The half of my week that is not visas goes into Apify Actors, and one of them reads short vertical video: give it Reel, TikTok or Shorts links — or a whole profile — and it returns one flat row per video with the transcript, the text burned into the picture, and the engagement numbers the platform showed.

Profile mode is what people buy it for: watch this creator, transcribe whatever they post. It is also where Instagram hands you a different dataset than the one you asked for, in two separate ways. I measured both on 18 October 2026, and the second one changes which videos your pipeline calls viral.

The setup

One run, logged out, no cookies, no official API: profiles instagram.com/nasa/ and instagram.com/natgeo/, twelve newest Reels each, on-screen text off. 24 rows, 24 transcribed, zero failures, 59 seconds end to end.

Then a second run, 19 seconds, with the ten own-authored Reels of one of those profiles pasted in as plain links. Same videos, different input shape.

The Reels tab is a grid, not an authorship list

Here is who actually wrote the twelve Reels that came back for @nasa:

nasa            3
astro_jessica   2
nasajohnson     2
eaglescheer     1
ravens          1
nasaadmin       1
astro_anil      1
nasaaero        1

Three of twelve. The rest are other accounts' Reels sitting on NASA's grid — other NASA centres, individual astronauts, two sports teams. One is from the Philadelphia Eagles cheerleaders, captioned An inspiration to us all, thank you for stopping by @astro_christina 💚, 864,791 views. A real Reel on a public page, correctly returned. Just not NASA's.

@natgeo is tidier and still not clean: ten of twelve are natgeo, one is natgeofamily, one is 911onabc — a Disney sibling show.

The mechanism is collaborator posts: a co-authored Reel is served on both profiles, and the owner field names whoever posted it. The page hands a logged-out visitor the grid as rendered — it has no concept of "only posts this account authored", and neither does any scraper reading it.

So if your question is how often does this creator post and what do they say, the profile count is not the answer. The field you need is already in the row:

mine = [r for r in rows if r.get("author") == "nasa"]

Which sounds obvious until you see what it costs downstream.

The baseline that never formed

Every row carries vsAuthorMedian: how many times a video beat its own author's usual, computed from the other videos by that author in the same run. At least three peers are required, otherwise the field is null — a ratio computed from one neighbour is a coin flip wearing a decimal point.

For @natgeo the ten own-authored Reels gave each other a baseline and the run flagged the outliers. For @nasa, three own Reels out of twelve, the baseline never formed: vsAuthorMedian, authorMedian and isOutlier came back null on all twelve rows. Twelve clean transcripts, no virality signal at all.

That is the right behaviour — pooling eight accounts into one median produces a number that means nothing — but it is not what you expect from "I asked for twelve videos". On a collab-heavy account you would have to raise the ask until twelve own-authored Reels fit inside it, and logged out you cannot: twelve is the whole ceiling.

Ten identical videos, two different virality answers

Now the second finding, and the one I would put on a sticker.

Instagram shows view counts on the Reels tab of a public profile. It does not show them on a single Reel page to a logged-out visitor. Same ten @natgeo Reels, run both ways:

videoId	views (profile run)	views (link run)	likes
DemLxMGgoL_	4,072,300	`null`	205,239
Dec1lmtgGYk	642,521	`null`	51,232
DeobYzjga9x	334,391	`null`	96,650
DehZj9wggt0	286,821	`null`	49,146
DeckcQnA23l	238,557	`null`	21,594
Delg3cUktih	189,002	`null`	10,379
DeeUUHNAqQj	188,567	`null`	14,570
Del2uq1gnwg	178,700	`null`	17,062
DefFZgggApb	172,808	`null`	43,590
DecPSQfoaRe	110,213	`null`	21,124

Likes survive both runs and agree to within 549 on the noisiest row — they are live counters, so small drift between two runs minutes apart is expected. Views simply are not in the single-Reel payload.

The Actor handles that by falling back: when every video in an author group has views it compares on views, otherwise on likes, and vsAuthorBasis says which. Honest, and still not interchangeable. Ranking those ten Reels by likes instead of views gives:

11 of 45 pairs in the wrong order (Spearman ρ = 0.71)
like-to-view ratio from 5.04% to 28.90% across the same ten videos of one account — a 5.7× spread
a different set of outliers

That last one is the part that reaches your dashboard. At the 3× threshold:

basis = views  ->  outliers: DemLxMGgoL_ (21.55x), Dec1lmtgGYk (3.40x)
basis = likes  ->  outliers: DemLxMGgoL_  (9.51x), DeobYzjga9x (4.50x)

One video in, one video out, on identical input videos. Dec1lmtgGYk pulled 642k views on a 7.97% like rate — broad reach, ordinary engagement. DeobYzjga9x got a third of that reach at a 28.90% like rate — a small, very warm audience. Views call the first a breakout, likes call the second. Both are defensible; neither substitutes for the other, and if half your rows arrived by link and half by profile, your "top videos" list is mixing two scales.

Practical rule: do not mix input shapes inside one analysis. Pull by profile when you need reach; if a Reel has to arrive by link, label its vsAuthorMedian as an engagement figure — vsAuthorBasis is in the row precisely so you can.

The twelve-item ceiling is a scheduling constraint

Instagram's logged-out Reels tab renders twelve items. That is not a parameter the Actor could raise; it is the page. Which means how often you need to run is set by how fast the creator fills twelve slots.

In my two runs the twelve newest Reels covered:

@nasa — 14 September to 10 October, 26 days
@natgeo — 13 October to 18 October, 5 days

A weekly watch on @natgeo would have silently missed Reels; on @nasa it would have been comfortable. Same ceiling, 5× difference in how long the window lasts. Measure the span of your first run, set the schedule to a fraction of it, and turn on "only videos not processed before" so the overlap costs nothing — already-seen videos are skipped before download and not billed.

What the whole exercise cost

24 Reels transcribed, speech recognition on, on-screen text off: $0.2422 total, per-row from $0.0028 to $0.0364. The cheap rows are the silent ones: four of the ten @natgeo Reels had no speech, came back with transcriptSource: no-speech, and were billed for the video event only, no audio charge. The expensive row was 236 seconds long. Re-running the ten Reels as links cost $0.0658.

Calling it is a POST and a read:

import requests, statistics

TOKEN = "<your apify token>"
rows = requests.post(
    "https://api.apify.com/v2/acts/lergassy~instagram-reels-transcript-scraper"
    "/run-sync-get-dataset-items",
    params={"token": TOKEN},
    json={
        "profiles": ["https://www.instagram.com/natgeo/"],
        "resultsLimitPerProfile": 12,
        "includeOnScreenText": False,
        "onlyNewVideos": True,
        "watchlistName": "natgeo-weekly",
    },
).json()

mine = [r for r in rows if r.get("type") == "reel" and r.get("author") == "natgeo"]
print(len(rows), "rows ->", len(mine), "authored by the profile")

basis = {r.get("vsAuthorBasis") for r in mine}
print("comparison basis:", basis)          # {'views'} by profile, {'likes'} by link

span = sorted(r["postedAt"] for r in mine)
print("window:", span[0], "->", span[-1])  # set your schedule inside this

Three lines of hygiene, in this order, before anything aggregates: filter on author, assert a single vsAuthorBasis, read the date span. Full field list and the input form: Instagram Reels Transcript Scraper.

When this is the wrong tool

If you need more than twelve Reels of a profile in one go, this is not it — and no logged-out scraper is, because the page stops there. Older Reels need their own links, which drops the views again. If you need historical view counts, also stop: Instagram reports a live counter, so a time series only exists if you start snapshotting now. And if your question is purely what was said, skip profile mode and paste links — authorship and reach stop mattering, and the whole problem above goes away.

The general lesson is not about Instagram. A profile endpoint answers "what is displayed on this page", and you read it as "what this account produced". Those two differ by nine rows out of twelve on a heavily collaborating account, and the field that tells you so is sitting in the response, ignored.

Airbnb Snapped 'Seminyak' to 'Kuta': 90 of 116 Listings Were Labelled Somewhere Else

Matvey — Sun, 18 Oct 2026 05:12:59 +0000

I run a visa agency in Bali. The other half of my week goes into Apify Actors, and one of them reads Airbnb search pages: you give it a place, two dates and a party size, and it returns one flat row per listing — total price for the stay, price per night, rating, review count, beds, coordinates.

The question people actually buy that for is a pricing question. What does a two-bedroom in Seminyak go for in mid-November? I live twenty minutes from Seminyak, which gave me an advantage over most of my own users: I could tell that several villas in the answer were not in Seminyak at all.

Here is what is going on, measured, because it changes every average you compute downstream.

The place you type is not the place that gets searched

Three scheduled runs, 16, 17 and 18 October 2026, same input every time: Seminyak, Bali, Indonesia, a three-night stay a month out, two adults, prices in USD, 60 listings. 180 rows, 116 unique listings across the three days.

Every row carries both the string I asked for and the place Airbnb decided I meant:

query : "Seminyak, Bali, Indonesia"
place : "Kuta, Indonesia"

Kuta is the kecamatan — the district. Seminyak is one village inside it. The search ran across the whole district, and the row says so, in a field most people never read.

What that does to the result set, counting the area label on all 116 unique listings:

Kuta                     37
Seminyak                 26
Kuta Utara               24
Kecamatan Kuta Utara     15
South Kuta                3
Umalas                    3
Kabupaten Badung          3
Pererenan                 2
Denpasar                  1
Berawa                    1
Kecamatan Denpasar Barat  1

Twenty-six of 116. Pererenan and Berawa are Canggu — a different beach, a different market, a 25-minute drive in traffic. Denpasar is the provincial capital, inland.

Coordinates confirm it. Taking Seminyak Beach as −8.6900 / 115.1685 and measuring great-circle distance per run:

Run	n	median	p90	max	beyond 5 km
16 Oct	60	1.5 km	4.0 km	7.4 km	3
17 Oct	60	1.3 km	3.7 km	7.1 km	3
18 Oct	60	1.4 km	3.9 km	7.1 km	3

Stable across days, so this isn't one odd page. The two farthest rows:

 7.4 km  Pererenan    $116.00/night  Villa Kayu: Chic Minimalist Retreat Near Beach
 7.1 km  Pererenan    $186.33/night  Super Unique & Stunning Architecture @Bocoa Villas

Airbnb obfuscates coordinates slightly before you book, so treat the sub-kilometre figures as soft. It does not obfuscate by seven kilometres.

The text label is the wrong filter

The obvious fix is to throw away everything where area != "Seminyak". That is worse than doing nothing, and the same 116 listings show why.

Sort by distance and look at the three closest rows in the whole sample:

 0.2 km  Kuta   $152.00/night  One Bedroom Villa with Private Pool in Seminyak
 0.2 km  Kuta   $ 78.33/night  The Catur Villa - Macaca 2BR Villa
 0.3 km  Kuta   $122.33/night  Calladi Villa 2BR Luxury with 300m² Big Garden

The nearest listing to the centre of Seminyak is labelled Kuta and has the word Seminyak in its own title. The label is whatever administrative string Airbnb happened to render for that card, and the list above shows it is not even one consistent level: village (Seminyak, Umalas, Pererenan), district (Kuta Utara), the same district again with the Indonesian prefix attached (Kecamatan Kuta Utara — 24 rows one way, 15 the other), and regency (Kabupaten Badung, which contains all of the above). You cannot GROUP BY that column.

So filter on geometry instead. Same 116 listings, two definitions of "in Seminyak":

Filter	n	median $/night	mean $/night
everything returned	116	112.00	113.48
`area == "Seminyak"`	26	127.67	137.47
within 1.5 km of the beach	68	108.33	105.32
beyond 1.5 km	48	116.00	125.03
beyond 3 km	18	119.33	131.69

The label filter reports a median 18% above the coordinate filter, on one dataset, for the same week and the same party size. It keeps 26 rows where the honest answer keeps 68, and the 26 are not a random subsample — Airbnb's label skews toward the expensive main-strip inventory. If you are a host setting a rate off that number you are pricing against a market that does not exist.

Mean rating barely moves between the bands (4.90 against 4.93) — the tell that the price gap is geography, not a quality split.

It isn't a Bali thing

Two more searches, 18 October 2026, same shape, from a throwaway account:

query : "Shoreditch, London, United Kingdom"
place : "Greater London, United Kingdom"

Greater London is roughly 1,570 km². Those 20 rows are much tighter than Bali's — median 0.4 km from Shoreditch High Street, 18 of 20 inside 3 km — but the two that escaped are the two that matter:

11.8 km  London    $ 36.33  A home away from home,
 6.9 km  Newham    $ 40.00  3 bedroom house
 0.7 km  London    $341.00  2BR Shoreditch Flat with Balcony, near the tube
 0.6 km  London    $297.67  Stylish 2-Bed Apartment In Shoreditch

Ten percent of the rows, and they set your floor: $36 against a Shoreditch core around $275–340. Any "cheapest available in Shoreditch" built on this is answering a question about Newham.

And the one that surprised me most:

query : "Williamsburg, Brooklyn, New York"
place : "New York City, NY"

A neighborhood of Brooklyn widened to the entire city. Five of those ten rows were not homes at all:

{
  "name": "Pod Brooklyn Hotel",
  "propertyType": "Pod Brooklyn Hotel",
  "area": null,
  "priceTotal": null,
  "pricePerNight": null,
  "badges": ["Featured hotel"],
  "bedInfo": [],
  "rating": 4.76,
  "reviewCount": 629
}

Airbnb's hotel inventory. No price in the search card, no area, no beds — and one of them, Pod 39, sits in Murray Hill in Manhattan, 4.3 km from Williamsburg. I deliberately emit null rather than 0 for those, because a zero would quietly drag an average down and nobody would notice. But len(dataset) is still not your sample size: asking for ten listings got me five priced homes.

What to actually do with the rows

Three lines, in this order, before any aggregation:

import math, requests

TOKEN = "<your apify token>"
r = requests.post(
    "https://api.apify.com/v2/acts/lergassy~airbnb-scraper/run-sync-get-dataset-items",
    params={"token": TOKEN},
    json={
        "locationQueries": ["Seminyak, Bali, Indonesia"],
        "checkIn": "2026-11-17", "checkOut": "2026-11-20",
        "adults": 2, "currency": "USD", "maxListings": 60,
    },
).json()

def km(lat, lon, alat=-8.6900, alon=115.1685):
    p = math.pi / 180
    return 2 * 6371 * math.asin(math.sqrt(
        math.sin((lat - alat) * p / 2) ** 2
        + math.cos(alat * p) * math.cos(lat * p) * math.sin((lon - alon) * p / 2) ** 2))

homes = [x for x in r
         if x.get("priceTotal") is not None                  # drops hotel cards
         and "Featured hotel" not in (x.get("badges") or [])
         and km(x["latitude"], x["longitude"]) <= 1.5]        # drops the next district

print(len(r), "rows ->", len(homes), "in scope")

Read place, not just query. If they differ, the search was widened and you now need a geographic cut. In my runs they differed in all three cities.
Cut on coordinates, with a radius you chose. Not on area, ever.
Drop the hotel cards before you average anything, or report them separately.

Pasting an Airbnb search URL into startUrls instead of typing a place does not save you — Airbnb resolves the place server-side either way, and the URL's own map bounds are advisory. The only honest boundary is the one you draw on the coordinates you got back. Actor and full field list: Airbnb Scraper.

When this is the wrong tool

If you need the exact street address, stop here — Airbnb only reveals it after booking, and no scraper changes that. If you need historic nightly rates, also stop: Airbnb quotes live availability, so a price series only exists if you start collecting now and keep the snapshots. And if your question is a single listing's amenities rather than a market's prices, run the listing URL directly — a search is the one thing that can hand you a price, and the one thing that will hand you the wrong neighborhood while doing it.

The general lesson has nothing to do with Airbnb. Any search endpoint that accepts free-text place names is doing geocoding you cannot see, and the polite ones tell you what they decided. Read that field. It is the difference between a market report and a confident average of the wrong town.

398 of 692 Products Were Published in One Afternoon. Zero Were Created in 90 Days

Matvey — Sat, 17 Oct 2026 21:11:51 +0000

I run a visa agency in Bali. The other half of my week goes into Apify Actors, and one of them profiles Shopify stores: you hand it a list of domains and it returns one flat row per shop — who the merchant is, the e-mails and socials they published, the theme and apps the storefront runs, catalogue size, price band.

Nobody buys that row for the price band. They buy it for one question that decides whether a store is worth a pitch, an outreach e-mail or a line in a market sizing: is anyone still working on this shop?

Shopify answers that question in public, for free, on every store that hasn't switched it off. It just answers it with two fields that look interchangeable and are not.

The measurement

On 17 October 2026 I read /products.json from four Shopify stores — no login, no API key, no proxy, the same JSON the storefront downloads for itself — and counted products two ways: how many were created in the last 90 days, and how many were published in the last 90 days.

Store	Sample	Created in 90 days	Published in 90 days
allbirds.com	692	0	404
ridge.com	750	157	295
deathwishcoffee.com	147 (whole catalogue)	17	37
kith.com	750	410	500

Every store reports more recent publishing than recent creation. That gap is the whole post. On a genuinely busy shop it's roughly a doubling and both numbers point the same way. On Allbirds the two fields disagree about whether the catalogue has moved at all this quarter: one says 404 products, the other says none.

Sort the Allbirds sample by published_at and the reason shows up immediately:

top published_at days: 2026-09-25 → 398 products
                       2026-06-16 → 222
                       2026-06-11 →  50
top created_at days:   2025-08-06 → 116
                       2025-07-23 →  44
                       2025-07-03 →  20
created_at by year:    2018: 5 · 2019: 7 · 2020: 11 · 2021: 28 · 2022: 35
                       2023: 85 · 2024: 154 · 2025: 340 · 2026: 27

398 of the 692 products in that sample carry a published_at inside one afternoon — the earliest at 14:51:05, the latest at 16:58:13 on 25 September 2026. Two hours and seven minutes for 58% of a catalogue that took eight years to build. Here is one of them:

Men's Canvas Runner NZ - Deep Navy Stripes
  created_at:   2025-12-04T12:15:25-08:00
  published_at: 2026-09-25T16:58:09-07:00
  updated_at:   2026-10-17T14:08:56-07:00

A product that has existed for ten months, stamped as published three weeks ago. The newest created_at anywhere in those 692 products is 2026-06-05 — four months before the run. The oldest is 2018-11-12.

I can't see from outside which admin operation did that: a sales-channel change, a market or theme migration, a bulk edit, a re-publish of unpublished seasonal lines. It doesn't matter for the consumer of the data. What matters is that published_at is not a creation timestamp and nothing in the payload says so. An activity metric built on it reports a store that added nothing in a quarter as the most active shop in your list.

`updated_at` is worse

The other candidate is the one most people reach for second. Don't:

allbirds.com        250 of 250 products · updated_at = 2026-10-17
deathwishcoffee.com 147 of 147 products · updated_at = 2026-10-17

Every product in both catalogues, 100% of each, updated today. Inventory sync, price feeds and app writes touch the record constantly, so updated_at is a heartbeat of Shopify's own plumbing, not of the merchant. As a freshness signal it has no variance at all, which makes it exactly as informative as a constant.

What the Actor counts instead

Nine lines, and the comment is the whole argument:

const now = Date.now();
// Count on created_at, not published_at: Shopify bumps published_at whenever a product is
// re-published, so a store that changed nothing all year still looks brand new.
const fresh = products.filter(
    (p) => p.created_at && (now - Date.parse(p.created_at)) < 90 * 864e5
).length;

created_at is the field that only moves once. It survives re-publishing, channel changes and theme migrations, because none of those create a product record — they touch one that already exists.

That lands in the store row as three fields: productsCreatedLast90Days, newestProductAt and oldestProductAt. Here is the real Allbirds row from a run of the published Actor on 17 October, trimmed to the parts under discussion:

{
  "rowType": "store",
  "shopName": "Allbirds",
  "myshopifyDomain": "weareallbirds.myshopify.com",
  "email": "help@allbirds.com",
  "emails": ["help@allbirds.com", "travis@allbirds.com", "press@allbirds.com", "info@afterpay.com"],
  "theme": "[DNAM Theme July 2026]",
  "productCount": 250,
  "totalProducts": 692,
  "catalogueComplete": false,
  "variantCount": 2720,
  "inStockVariants": 495,
  "outOfStockVariants": 2225,
  "priceMin": 4, "priceMedian": 80, "priceMax": 165,
  "newestProductAt": "2026-05-26T11:10:21-07:00",
  "oldestProductAt": "2018-11-12T14:25:43-08:00",
  "productsCreatedLast90Days": 0,
  "pageCount": 175,
  "firstPageAt": "2017-04-25T14:22:24-07:00"
}

Three other numbers in that row point the same direction as the zero: 2,225 of 2,720 variants out of stock, and a catalogue whose oldest content page dates to April 2017. That's a store with eight years of history and nothing new on the shelf this quarter — which is a perfectly good thing to know before you spend a sales hour on it, and the exact opposite of what published_at would have told you.

Two caveats, because this is not a law of nature

created_at lies about replatforming. It records when the record was made, not when the product existed. Kith shows 665 of 750 sampled products created in 2026 and 1 in 2018. Some of that is a genuinely fast fashion catalogue; some of it is what happens when a catalogue is rebuilt or bulk-imported, because every imported product gets a brand-new created_at. A store that migrated last month looks newborn on this metric. There is no public field that survives that, and I'm not going to pretend otherwise — the honest read is "this record is young", not "this business is young".

The sample is not the catalogue. /products.json pages out at whatever cap you set — 250 by default. Allbirds returned productCount: 250 against totalProducts: 692, counted separately from the store's product sitemap, with catalogueComplete: false saying so out loud. Kith came back 250 against 34,970. Every catalogue figure in the row, including the 90-day count, describes the sample; the Actor's own newestProductAt for Allbirds reads 2026-05-26 from its 250-product sample against 2026-06-05 across all 692. If the activity number is what you're buying, raise the per-store product cap and read catalogueComplete before you trust it.

The fourth store

One of the four addresses in that run never produced a profile:

{
  "rowType": "error",
  "storeUrl": "https://ridge.com",
  "error": "The shop refused the request (HTTP 403), so it could not be checked. Slow the run down with fewer parallel stores, or try again later.",
  "scrapedAt": "2026-10-17T21:09:32.400Z"
}

ridge.com rate-limited the Actor during the run, having answered a plain request from the same machine a few minutes earlier — that's the 157/295 row in the table above. The thing I care about is that it comes back as refused, not as isShopify: false. A scraper that reports a 403 as "not a Shopify store" silently deletes real shops from a prospect list and gives you no way to notice. Error rows cost nothing and one bad address doesn't stop the run.

Calling it

One HTTP call, rows back in the same request:

curl -X POST "https://api.apify.com/v2/acts/lergassy~shopify-store-intel/run-sync-get-dataset-items?token=<TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"storeUrls":["allbirds.com","deathwishcoffee.com"],"mode":"store","maxProductsPerStore":250}'

Four addresses in store mode took 22 seconds end to end. The Actor is shopify-store-intel; the dates, the 403 and the Allbirds row above all come from that run.

When not to bother

If you only need to know whether a domain is Shopify, don't profile it — detect mode answers that from one request. If you need stock levels or sales volume, this is the wrong data source entirely: /products.json publishes an available boolean per variant and no quantities, and nothing public tells you what sold. And if your list is stores you already know are active, the activity fields are dead weight — buy the contacts and skip the catalogue.

But if the list is 5,000 domains scraped off a directory and your real question is which 400 are worth a human reading them, count creations. Counting publications tells you when somebody last clicked Save.

Three of Five Founder Mailboxes Rejected first.last, the Layout Everyone Defaults To

Matvey — Sat, 17 Oct 2026 13:12:16 +0000

I run a visa agency in Bali, and the other half of my week goes into Apify Actors. One of them is narrow on purpose: you give it a LinkedIn profile URL, it gives you back the person's name, title, current company, location — and their work e-mail address with the mailbox checked over SMTP.

The part that looks like the hard problem is finding the address. It isn't. Writing first.last@domain.com takes one line of code, and that is exactly what most of this category ships, with a label like deliverable next to it. The hard problem is the one that appears the moment you actually ask a mail server whether the thing you just wrote down exists: you only get a couple of questions, so the order you ask them in is the product.

Here is what that costs, measured on nine runs between 10 and 17 October 2026 across six public profiles of founders and executives (builds 0.1.32 to 0.1.41).

The ranked guess was wrong more often than it was right

Every one of the six people got the same treatment: read the public profile, resolve the company to a domain, build candidate addresses in the company's own layout, then check mailboxes over SMTP — at most two per person — and keep the first one the server confirms.

Person	Domain	Check 1 (ranked first)	Check 2	Delivered
Bill Gates	gatesfoundation.org	`bill.gates@` → `safe`	—	`bill.gates@`
Garry Tan	ycombinator.com	`garry.tan@` → `safe`	—	`garry.tan@`
Satya Nadella	microsoft.com	`satya.nadella@` → `invalid`	`satya@` → `safe`	`satya@`
Rand Fishkin	sparktoro.com	`rand.fishkin@` → `invalid`	`rand@` → `safe`	`rand@`
Jeff Weiner	nextplayventures.com	`jeff.weiner@` → `invalid`	`jeff@` → `safe`	`jeff@`
Patrick Collison	stripe.com	`patrick.collison@` → `catch_all`	`patrick.collison@arcinstitute.org` → `catch_all`	nothing

Five of the six ended with a mailbox the server confirmed. In three of those five the highest-ranked candidate came back invalid — not "unconfirmed", not "probably", but a mail server actively saying there is no such mailbox. The address that worked was the plain first name.

Six people is not a statistical law about corporate mail, and I'm not going to dress it up as one. It is, however, a direct cost argument. If your highest-ranked candidate fails 60% of the time on the kind of person people actually pay to reach, then a tool with no mailbox check hands out three wrong addresses in five with a confident label on each, and a tool with a mailbox check spends 60% of its check budget on check 1.

Why the default led in all six cases

The Actor's first choice of layout is not supposed to be a default. It's supposed to be evidence:

// The whole product rests on one observation: a company that publishes any personal
// address on its own website has told you the rule for all of them. jane.doe@acme.com
// on the team page means the sales director is firstname.lastname too.

If the company site publishes j.diaz@acme.com and m.kent@acme.com, you don't guess — you've been told the layout, and you write the one address you were asked for in it. That path works, and I wrote about the evidence side of it separately. It just didn't fire once in this batch. All six rows came back with patternEvidenceCount: 0 and emailPatternSource: "default": gatesfoundation.org, microsoft.com, stripe.com, ycombinator.com, sparktoro.com and nextplayventures.com publish no personal address a crawler can read. Big companies route you to a contact form; two-person funds have a hello@.

With nothing to learn from, the ranked prior takes over, and the prior is this list:

export const PATTERNS = [
    'first.last', 'first', 'flast', 'firstlast', 'first_last', 'firstl', 'f.last',
    'last.first', 'lastfirst', 'first-last', 'last', 'fl',
];

first.last is roughly half of corporate mail, so it leads. But look at who rejected it: the CEO who joined in 1992, the founder of a two-person company, a founding partner of his own fund. People who were employee number small tend to hold the short mailbox, and the short mailbox is first@. The population you want from LinkedIn — founders, partners, heads of things — is enriched in exactly the people for whom the most common layout is the wrong one.

The budget is two checks, and that's the whole design

const REOON_MAX_CHECKS = 2;
…
const pool = candidatesFor(first, last, company.domain, company.pattern || 'first.last', …);
const order = [...(onSite ? [onSite] : []), ...pool.filter((c) => c.email !== onSite?.email)];
v = await verifyFirst(order.map((c) => c.email), { maxChecks: REOON_MAX_CHECKS });

Two, not ten, for two unglamorous reasons. Each check is a paid API call, and the Actor charges per found e-mail — so checks that find nothing come out of my margin, not the buyer's bill. And hammering one domain with ten mailbox probes per person is how a verification provider's IPs stop being trusted by that domain's mail server.

Which means the ranking is not a nicety. With a budget of two, "the right layout is third in my list" and "I have no address for this person" are the same outcome. The three saves above all happened on check 2. There is no check 3.

That also explains a field people ask about. alternatives in every row is not padding — it's the rest of the ranked list that never got measured, labelled as such, so a buyer whose first address bounces has somewhere to go:

"email": "satya@microsoft.com",
"emailPattern": "first",
"confidence": "verified",
"emailStatus": "mailbox-verified",
"emailVerification": { "provider": "reoon", "status": "safe", "score": 98, "checks": 2,
  "tried": [ { "email": "satya.nadella@microsoft.com", "status": "invalid" },
             { "email": "satya@microsoft.com", "status": "safe" } ] },
"alternatives": [ { "email": "satya.nadella@microsoft.com", "pattern": "first.last" },
                  { "email": "snadella@microsoft.com", "pattern": "flast" } ]

Where no amount of check budget helps

stripe.com answered catch_all to patrick.collison@stripe.com in all six runs it appeared in, with a score of 75 against the 98 a confirmed mailbox gets. A catch-all server accepts every address you offer it, including ones you invent, so nothing can be confirmed there — not by me, not by any vendor, no matter what their UI says. The remaining check rolled to the person's other current company from the profile, arcinstitute.org, which is also catch-all. Two checks spent, nothing learned:

"email": null,
"emailGuess": "patrick.collison@stripe.com",
"emailCatchAll": true,
"emailStatus": "catch-all",
"summary": "Not delivered as an e-mail: the mail server of stripe.com accepts any address
            (catch-all), so no mailbox can be confirmed there; best unverified guess
            patrick.collison@stripe.com is in \"emailGuess\". This row was not charged."

The guess still ships, in a differently-named field, free. If you're building this yourself, that split is the only honest shape I've found: one field for "a server confirmed this", a different field for "this is my best construction", and never the same field for both.

The failure that only shows up when you run the same thing twice

One run out of nine broke the pattern. On 13 October, microsoft.com answered unknown to satya.nadella@microsoft.com after a single check — no score, no verdict — where the eight other runs got a flat invalid on that same address. The row came back free, no e-mail, status mailbox-unknown.

That's the right outcome for billing and the wrong one for the buyer, and it exposes a limit I'd rather print than hide: because the run stopped at unknown instead of invalid, it never reached satya@, and emailGuess was filled with satya.nadella@microsoft.com — the exact address eight other runs proved does not exist. Nothing in a single row is wrong. The row simply can't know what a different run knew. If you're consuming SMTP verdicts in a pipeline, treat unknown as "ask again tomorrow", never as "no mailbox", and keep your own memory of addresses that came back invalid across runs.

Calling it

curl -X POST "https://api.apify.com/v2/acts/lergassy~linkedin-email-finder/run-sync-get-dataset-items?token=$APIFY_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"profileUrls":["https://www.linkedin.com/in/satyanadella",
                      "https://www.linkedin.com/in/patrickcollison",
                      "https://www.linkedin.com/in/williamhgates"]}'

Those three profiles took 14.6 seconds end to end in the 17 October run these numbers come from, and about $0.0006 of platform compute; the price is per e-mail found, and the two catch-all and unknown rows above cost nothing. It's LinkedIn Email Finder on Apify if you want the rows rather than the reasoning.

Where it doesn't fit: there's no login, so the roughly one profile in five that LinkedIn hides from anonymous readers needs an unblocking route and sometimes still doesn't open. If your target list is all large-enterprise domains, expect a pile of catch-all rows and plan on guesses. If you already have a name and a company domain and no LinkedIn URL, the profile read is wasted work — the name-plus-domain path is a different Actor. And if your list is twenty people, reading twenty company websites by hand will beat any of this.

What I'd keep even if you never run it: a mailbox check turns e-mail finding from a text-formatting exercise into a search problem with a budget. Spend the budget on the layout the company told you about. When it hasn't told you anything, know that your prior is tuned for the median employee, and the people you're looking for aren't median.

Allbirds' Home Page Carries No Ad Pixel. Its Tag Container Carries 23 Account IDs

Matvey — Sat, 17 Oct 2026 05:14:01 +0000

I run a visa agency in Bali. The other half of my week goes into Apify Actors, and one of them does something narrower than a general tech-stack lookup: you give it a list of domains, it gives you back one row per domain with the technologies the site runs, the capabilities it lacks, whether the company is spending on traffic right now, and the e-mail and phone to reach it.

The "lacks" column is the whole point. Nobody replies to "I see you use WordPress". People reply to "you're running Meta ads but a visitor can't book an appointment on your site". The problem is that a missing-capability list is a negation, and a negation is only as trustworthy as your detection. Every tool you fail to see becomes a gap you'll put in an e-mail and be wrong about.

Here is the single biggest source of those wrong gaps, measured on 23 live domains on 17 October 2026.

The home page knows nothing

allbirds.com, home page, about 700 kB of HTML. I grepped it for every advertising identifier I could think of:

GTM containers:        GTM-TH8KRSBJ
Google Ads (AW-…):     (none)
GA4 (G-…):             (none)
fbq('init', …):        (none)
connect.facebook.net:  0 occurrences
analytics.tiktok.com:  0 occurrences

Allbirds is not a company that has stopped advertising. The page just doesn't contain its advertising. All it contains is the loader for container GTM-TH8KRSBJ. So I fetched that container — it's a public JavaScript file, no auth, https://www.googletagmanager.com/gtm.js?id=GTM-TH8KRSBJ, 656 kB — and grepped the same patterns:

Google Ads:  AW-604448474  AW-671743546  AW-736740096  AW-786649265
             AW-798041621  AW-822752074  AW-822752224
GA4:         G-KJL05B1DJZ  G-KB1068K0E6  G-K4JD0P61SJ  G-X7QTYLMX8J … (10 unique)
Meta pixels: 1758221267590067  1689016458013442  1569821056431325 … (8 unique)
TikTok:      2 occurrences of analytics.tiktok.com

That's the whole asymmetry in two greps. The tags are not in the page; they are in a file the page tells the browser to go and get. A scraper that reads HTML and stops is reading the table of contents.

What it does to the output

So the scanner fetches the container for every domain that loads one and runs detection over HTML plus container body. To find out what that's worth I ran the same 23 domains twice, once with expandTagManager: true and once with it off — 11 e-commerce brands, 8 local businesses (dental and roofing) and 4 vertical SaaS sites. 20 answered, 3 were blocked.

Over the 20 reachable sites	HTML only	HTML + container
Sites flagged as paying for traffic	6	14
Distinct ad platforms detected	8	31
Technologies detected	79	124
Gaps reported	126	106
Sites reported as `no_ads_pixel`	14	6

11 of the 20 sites load a GTM container, and on 8 of them the container flipped runsPaidAds from false to true: allbirds.com, warbyparker.com, ruggable.com, chubbies.com, bostondentalgroup.com, mrroof.com, housecallpro.com, nexhealth.com. Every one of those 8 would otherwise have gone out with no_ads_pixel in its gap list — a brand running five pixels, described to a prospect as a company with no tracking.

The 20 gaps that disappeared weren't all ad pixels either:

no_ads_pixel        8
no_analytics        7
no_reviews_widget   1
no_online_payments  1
no_email_capture    1
no_crm              1
booking_unverified  1

Two of those are worth naming. bostondentalgroup.com loads Sunbit — patient financing, i.e. an online payment capability — from inside its container; HTML-only called it no_online_payments. And mrroof.com went from 7 gaps to 3, because the container held both its CRM tag and a booking vendor, so booking_unverified resolved into an actual identified vendor. On that one domain, four of seven "opportunities" were fiction.

Dropping 20 of 126 gaps sounds like a modest 16% correction until you remember which direction it runs. A gap list is a buy signal. The error mode of HTML-only scanning is never "I missed an opportunity" — it's always "I invented one", and you find out after you've sent the mail.

The cost of the extra fetch

One more HTTP request per domain, not a browser. That matters for anybody building the same thing: the honest-looking solution here is "render the page in Chrome and watch the network tab", and it works, and it costs an order of magnitude more per row. The container is a static file; you don't need to execute it to read which tags it carries.

The guard rails in the implementation are boring on purpose — at most 2 containers per site, a 3 MB cap on each, a shared timeout, and a Promise.all so the containers for one site come in parallel:

export async function expandTagManager(html, timeoutMs = 20000) {
  const ids = findContainerIds(html).slice(0, MAX_CONTAINERS);
  if (ids.length === 0) return { containerIds: [], body: '', adAccountIds: {} };

  const bodies = await Promise.all(ids.map((id) => fetchContainer(id, timeoutMs)));
  const body = bodies.join('\n');

  const uniq = (re) => [...new Set([...body.matchAll(re)].map((m) => m[0]))].slice(0, 8);
  const adAccountIds = {
    metaPixelIds: uniq(/\b\d{15,16}\b/g),
    googleAdsIds: uniq(/\bAW-\d{6,}\b/g),
    ga4Ids: uniq(/\bG-[A-Z0-9]{8,12}\b/g),
  };
  …
}

Where this is still wrong, in writing

Four limits I'd want to know about if I were reading someone else's row:

adAccountIds is capped at 8 per type. My own grep found 10 unique GA4 IDs in the Allbirds container; the row carries 8. One of the two dropped is G-D6E2XB4D2P, sitting in a lookup table keyed to allbirds.co.nz — the container holds the whole international estate, not one property. Treat the field as evidence that accounts exist, not as an inventory. Same regex, same caveat: a literal G-XXXXXXXXXX placeholder in a container matches the GA4 pattern as happily as a real ID.

adAccountIds reads only the container. roofingbybruce.com has a hardcoded gtag/js?id=G-41VCL68TF2 in its HTML plus two other GA4 IDs in its container. The technology "Google Analytics 4" is detected correctly; the ID from the page itself never appears in ga4Ids. The categorical answer and the identifier list come from different places, and only one of them sees the HTML.

Other injectors aren't expanded. Server-side GTM and Segment load tags somewhere this approach can't follow. A site whose tags arrive that way still reads as a gap.

It's one page. The scanner reads the home page. A booking widget living only on /appointments reads as booking_unverified if the page mentions scheduling and as a flat gap if it doesn't — which is why those are two different values rather than one.

Three of the 23 domains never produced a row at all, and they're instructive about the other half of this job: bombas.com answered 429 to both fetch engines, and clio.com answered 403 to both. baker-roofing.com and getjobber.com also answered 403 to a plain fetch — then returned 200 with 227 kB and 537 kB to a retry with a browser-shaped TLS handshake, same machine, same moment. Node's TLS fingerprint is recognisable; the header set isn't the thing being read. Blocked rows come back as status: "unreachable" with the code, because a list where failures vanish silently is worse than a list with holes in it.

Calling it

curl -X POST "https://api.apify.com/v2/acts/lergassy~website-tech-gap-scanner/run-sync-get-dataset-items?token=$APIFY_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"domains":["allbirds.com","bostondentalgroup.com"],"onlyPaidTraffic":true}'

Three domains took 4.3 seconds end to end in the run these numbers come from. A trimmed row:

{
  "domain": "bostondentalgroup.com",
  "finalUrl": "https://www.bdgdentalservices.com/",
  "confidence": "high",
  "prospectScore": 65,
  "prospectTier": "hot",
  "runsPaidAds": true,
  "adPlatforms": ["Meta Pixel"],
  "tagManagerContainers": ["GTM-MFVLQ3J"],
  "adAccountIds": { "metaPixelIds": ["473376469722887", "421033821700845"],
                    "ga4Ids": ["G-FKKWNQNGDB"] },
  "technologies": ["Google Tag Manager", "Google Analytics 4", "Universal Analytics",
                   "Meta Pixel", "WordPress", "Sunbit"],
  "gaps": ["booking_unverified", "no_live_chat", "no_crm", "no_email_capture",
           "no_reviews_widget", "no_contact_form"],
  "bookingSignals": ["schedule appointment", "schedule an appointment"],
  "city": "Las Vegas", "stateCode": "NV", "locationSource": "page text",
  "phones": ["7023998888", "7024324329", "7025222888"]
}

The Actor is Website Tech Gap Scanner on Apify. Where it doesn't fit: if you want a complete inventory of what a company runs across its whole estate, this is a home-page snapshot and you want BuiltWith's historical database instead; if you want contacts rather than stack, a dedicated contact crawler reads more than one page and will do better; and if your list is 50 domains you can check by hand, checking by hand is more accurate than any of this.

What I'd take away even if you never touch the Actor: if you're writing your own detector, the HTML is the loader and the container is the payload. Deciding what a website doesn't have on the strength of the loader alone will hand you a pile of confident, specific, wrong openings.

8% of My Capterra Reviews Arrived as the Three Characters $62

Matvey — Fri, 16 Oct 2026 21:22:16 +0000

I run a visa agency in Bali. The half of my week that is not visas goes into Apify Actors, and one of them reads B2B software reviews — Capterra, Software Advice, GetApp, TrustRadius — and returns all four with the same field names.

Last night I was grepping my own output for junk. Not looking for anything in particular, just running a regex for field values that look like machinery rather than text. One hit came back often enough to stop me:

{
  "reviewId": "Capterra___7209002",
  "title": "Slack: Essential for remote work productivity...and employee engagement",
  "overallRating": 5,
  "pros": "$62",
  "cons": "Honestly, not much. The only time I get frustrated with it is when I need to invite partners (from external companies) into our workspace for targeted deal collaboration…",
  "comments": "$61"
}

cons is a real review. pros is the string $62. Not an empty field, not a truncation, not a price — a three-character pointer where 1,309 characters of someone's opinion of Slack should be.

How often, and to whom

I keep every run's dataset, so this is measurable rather than anecdotal. Across 16 runs and 409 Capterra review rows, 35 rows — 8.6% — carried a pointer in at least one text field: 34 in pros, 12 in comments, never in cons. On Software Advice, 5 pointer fields across 150 rows. On TrustRadius, 0 across 1,330.

The TrustRadius zero is the clue. TrustRadius goes through a completely different code path in my Actor — one that reassembles each review out of a slice of markup. Capterra and Software Advice share a path that reads structured objects out of the page. So this was not a site change. It was my parser, and it had been wrong since at least late September.

What `$62` actually is

Capterra runs on Next.js App Router, which means the page does not ship a single JSON blob. It ships a React Server Components stream, pushed into the document in pieces:

<script>self.__next_f.push([1,"1:\"$Sreact.fragment\"\n3:I[339756,[\"/assets-bx-capterra/…"])</script>

Concatenate those pushes and you get a flat wire format of numbered rows. Mostly they are component references, but some are text:

61:T425,Slack has been part of the corporate toolkits of the companies I've worked for since 2017…

Row 61, type T, length 0x425 = 1,061 bytes, then the text. And in the review object that owns that text, React leaves this:

{"reviewId":"Capterra___7209002","overallRating":"5.0",
 "consText":"Honestly, not much. The only time I get frustrated with it is when…",
 "generalComments":"$61","prosText":"$62"}

That is React's reference syntax. A $-prefixed string in an RSC payload is a pointer to another row, not a value. The serializer outlines a long string — hoists it out of the object graph into its own row — and substitutes the pointer. The threshold in React's flight serializer is 1,024 characters.

I had read none of this. My parser pulled balanced JSON objects out of the stream, found "prosText": "$62", and dutifully wrote $62 into the dataset as the review.

Why a line-based reader misses the rows

The obvious fix is to build a lookup table of rows and resolve pointers against it. My first attempt did it by splitting the stream on newlines and matching ^([0-9a-f]+):T([0-9a-f]+),. It found row 61 and reported rows 62 and 63 as missing — even though 62:T51d, is right there in the HTML.

Here is the reason, lifted from the raw stream:

…companies should seriously consider adopting it.62:T51d,Since 2020, I've worked remotely as…

A text row declares its length, so it does not need a terminator — and it does not get one. The next row id begins immediately after the last byte of the previous row's text. On a line-based split, the only text rows you find are the ones that happen to follow a newline-terminated row. Every text row that follows another text row disappears, which is exactly the case when a page has several long reviews in a row.

So the rows have to be walked in order, and the length has to be honoured in bytes, not characters — T counts UTF-8 bytes, and review text is full of smart quotes and emoji:

_RSC_ROW = re.compile(rb'([0-9a-f]{1,8}):')
_RSC_TEXT = re.compile(rb'T([0-9a-f]+),')

def rsc_text_rows(blob: str) -> dict[str, str]:
    """Map every length-prefixed text row in the stream to the text it carries."""
    raw = blob.encode('utf-8')
    rows, position, size = {}, 0, len(raw)
    while position < size:
        head = _RSC_ROW.match(raw, position)
        if not head:
            newline = raw.find(b'\n', position)
            if newline < 0:
                break
            position = newline + 1
            continue
        body = head.end()
        text = _RSC_TEXT.match(raw, body)
        if not text:
            newline = raw.find(b'\n', body)
            position = size if newline < 0 else newline + 1
            continue
        start = text.end()
        end = min(start + int(text.group(1), 16), size)
        rows.setdefault(head.group(1).decode(), raw[start:end].decode('utf-8', 'ignore'))
        position = end + 1 if raw[end:end + 1] == b'\n' else end
    return rows

Then resolving is a recursive walk over the parsed object, replacing any string that is exactly $<row id> with that row's text. One detail worth stealing: React escapes a string that genuinely starts with $ by doubling it, so a reviewer who wrote $62 a month is fair arrives as $$62 a month is fair. That means a single-$ value is always a pointer and never literal text — and that a parser which ignores all of this also silently doubles the dollar sign on any review starting with a price. I had zero of those in 2,947 rows, so that half is read from React's source rather than measured, but it costs one line to handle:

if value.startswith('$$'):
    return value[1:]

The bias is the real damage

8.6% of rows losing a field sounds survivable. It isn't, because the loss is not random.

Here are the longest text values on one Capterra page for Slack — the 25 reviews on page 1 — split by whether React kept them inline or outlined them:

	Characters
Longest inline value	927
Shortest outlined value	1,061
Other outlined values	1,309 and 1,966

There is no overlap, and there can't be: the cut is React's 1,024-character rule. So the fields that went missing were precisely the three longest pieces of writing on the page. The 150-character "great tool, love it" reviews all came through perfectly.

If you are scraping reviews to feed a summarisation prompt, sentiment model or RAG index, that is the worst possible sample to lose. Short reviews are noise; the 2,000-character one from the IT executive explaining what Slack replaced and why is the entire reason to buy review data. My dataset was quietly dropping the signal and keeping the filler, and every run finished green with the expected row count.

That is the part I keep coming back to. The run succeeded. The row count was right. Nothing errored, nothing timed out, no site blocked anything. The only symptom was a two-byte string in one field of one row in twelve, and the only reason I found it is that I ran a regex looking for values that don't look like prose.

After

Same page, same 25 reviews, after the fix — and verified on the platform, not just on my laptop:

reviews: 25   pointer fields: 0
longest pros lengths: 1966, 1309, 926, 843, 805

Rows 1,966 and 1,309 are the two that used to be $63 and $62. The 926 was always fine. Both Actors that share this code path — Capterra & SaaS Reviews Scraper and its sibling — went out the same evening.

What to take from this if you scrape Next.js

Any $-prefixed string value in an RSC payload is a pointer. If your scraper reads App Router pages and never resolves them, you are losing your longest strings right now and your row counts look fine.
Length-prefixed rows are not newline-terminated. Walk the stream; don't split it.
Add a junk canary to your validator. Mine is one regex over every string field: ^\$[0-9a-f]{1,8}$. Values that look like machinery — pointers, $undefined, bare [object Object], NaN — are cheap to detect and are the ones that pass every other check.
Headless browsers don't have this problem. Read the rendered DOM and React has already resolved its own pointers for you. You pay a browser per page for it, which is why I parse the stream instead — but if you're scraping a handful of pages a day, that trade may not be yours.
Check field-length distributions, not just fill rates. A fill-rate check would have given this a clean bill of health: pros was populated in 100% of rows. It was populated with $62.

The reviews were there the whole time, 1,061 bytes further down the same response. I just never followed the pointer.

PrizePicks Gave Me Nine Pass-Yard Lines for One Quarterback. Eight Are Over-Only

Matvey — Fri, 16 Oct 2026 13:16:00 +0000

I run a visa agency in Bali. The other half of my week goes into Apify Actors, and one of them reads the two big pick'em apps — PrizePicks and Underdog Fantasy — and returns both boards as one table.

Pick'em is not sportsbook betting. There is no moneyline and no spread; the app posts a number for a player and a stat, and you say over or under. The number is the product. So the obvious thing to build is a comparison: same player, same stat, two apps, who asks for less.

That join is where everyone — me included, on the first try — gets it wrong. Not because the data is dirty, but because the two boards are not the same shape, and nothing in either payload announces that.

Here is a run from this afternoon, 16 October 2026: props mode, both apps, NFL, 600 rows, one run.

The shape problem in one table

	PrizePicks	Underdog
Rows returned	473	127
Distinct player + stat pairs	125	127
Rows per pair	3.78	1.00
Prices published	none	all 127 rows

Underdog shipped exactly one row for every player-and-stat pair — 127 of 127, no duplicates, every one two-sided and priced. PrizePicks shipped 473 rows covering 125 pairs.

Those extra 348 rows are not a paging bug. PrizePicks posts a ladder: the board line plus boosted alternates at other numbers. oddsType names them — standard is the board line, a demon is a harder number that pays more, a goblin an easier one that pays less.

Across the whole pull:

`oddsType`	Rows
demon	249
goblin	128
standard	96
balanced (all Underdog)	127

Only 96 of 473 PrizePicks rows are the number on the board. If you average line grouped by player and stat, you are averaging a marketing ladder.

Nine rungs, one board number

The deepest ladder in the run, C.J. Stroud's passing yards:

`line`	`oddsType`	`allowedPicks`
189.5	goblin	over
199.5	goblin	over
224.5	goblin	over
246.5	goblin	over
256.5	standard	under_or_over
264.5	demon	over
266.5	demon	over
269.5	demon	over
374.5	demon	over

Nine rows, one player, one stat, a 185-yard spread from bottom to top. The board number is 256.5. Everything else is a priced-up offer sitting on the same player.

And look at the third column, because that is the one that actually bites. Eight of those nine rows are over-only. You cannot take the under on a goblin at 189.5. It isn't a line in the sense you mean when you say "line" — it is a one-sided offer that happens to be rendered as a number. Pull these rows into a model as symmetric over/under lines and you have invented bets the app does not sell.

Ladder depth across the 125 pairs:

Rows for the pair	1	2	3	4	5	6	7	8	9
Pairs	38	10	17	10	16	9	12	11	2

Nearly 70% of pairs carry at least two rows, and in the compare mode only 2 of 46 standard lines had no alternates behind them at all. The median standard line was hiding six or seven.

`oddsType` and `allowedPicks` disagree, so read both

The tempting shortcut is oddsType == 'standard'. I used it, then cross-tabbed the two fields on the same 473 rows:

`oddsType`	`allowedPicks`	Rows
demon	over	240
goblin	over	117
standard	under_or_over	75
standard	null	16
goblin	under_or_over	11
demon	under_or_over	9
standard	over	5

Three surprises in that table. Twenty boosted alternates are two-sided. Five standard lines are not — they are over-only despite being the board number. And 16 rows don't say at all: allowedPicks comes back null on every Anytime TDs (Combo) row and, less explicably, on seven plain Rec Targets rows.

So the payout type and the permitted sides are independent facts, and one of them is sometimes missing. Treat null as unknown, never as two-sided.

The other thing you lose with a standard filter: 29 of the 125 pairs have no standard row at all. Chris Rodriguez Jr.'s longest rush, Nico Collins' receptions — demons and goblins only. Filter to standard and 23% of the board silently disappears, which is worse than keeping the ladder, because a short list looks like a correct list.

Seven of thirty stat names match

Now the join. PrizePicks used 30 distinct stat names in this run, Underdog 31. Names that match exactly: seven.

FG Made, Kicking Points, Longest Rush, Pass Attempts, Pass TDs, Pass Yards, Rush Yards. That's it. Everything else needs translating:

PrizePicks	Underdog
Rec Yards	Receiving Yards
Recs	Receptions
Rec Targets	Targets
Rush Atts	Rush Attempts
Longest Rec	Longest Reception
Rush+Rec Yds	Rush + Rec Yards

Thirty of the 46 comparison rows in my compare run pair two differently-spelled names. A join on raw strings would have returned 16 rows and looked like it worked.

Fuzzy matching is worse than useless here, and this run has the proof sitting right in it. PrizePicks publishes eight (Combo) markets — multi-player parlay-style props — and one of them is literally named Receiving Yards (Combo). Any substring or token-overlap matcher pairs that against Underdog's single-player Receiving Yards. Meanwhile Underdog's plain NFL board carries eight partial-game markets inline — 1H Rush Yards, 1Q Receptions, 1H Rush + Rec TDs — which share every meaningful token with the full-game stat and are a completely different bet. Rush+Rec Yds versus Receiving Yards scores high on most similarity metrics too.

The only thing that works is an explicit alias table and an explicit exclusion list. Boring, finite, and it does not quietly invent pairs on a slate you didn't look at.

What the comparison actually found

Compare mode, same slate, 46 pairs:

Line difference	Pairs
0	17
0.5 – 2	14
3 – 5	11
6 – 7	4

The marketing claim about these apps is that they rarely agree. On this slate they agreed exactly on 37% of shared props. Where they differed, PrizePicks had the easier over 16 times and Underdog 13.

The widest gaps, and the thing to notice about them:

Player	Stat	PrizePicks	Underdog	Gap	Easier over	PP alternates
C.J. Stroud	Pass Yards	256.5	249.5	7	underdog	8
Dalton Schultz	Rec Yards	31.5	24.5	7	underdog	7
Bijan Robinson	Rush+Rec Yds	123.5	129.5	−6	prizepicks	6
Bhayshul Tuten	Rec Yards	8.5	14.5	−6	prizepicks	5

Seven yards on Stroud's 250 is noise. Seven yards on Schultz's 24.5 is a 29% disagreement about a tight end. Absolute line difference is the wrong unit for comparing across stats, and the field is deliberately raw so you can divide by whatever you like.

Also: easierOver is null on all 17 ties rather than naming a winner. Those are ties, not wins.

Calling it

One player, both boards, everything including the ladder:

curl -X POST "https://api.apify.com/v2/acts/lergassy~dfs-props-scraper/run-sync-get-dataset-items?token=$APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"mode":"props","players":["Stroud"],"maxRows":50}'

Board lines only, with the ladder depth kept as a number:

from apify_client import ApifyClient

client = ApifyClient("<TOKEN>")
run = client.actor("lergassy/dfs-props-scraper").call(run_input={
    "mode": "compare", "leagues": ["NFL"], "maxRows": 200,
})
for row in client.dataset(run["defaultDatasetId"]).iterate_items():
    rel = abs(row["lineDifference"]) / row["underdogLine"]
    print(row["player"], row["market"], row["prizePicksLine"],
          row["underdogLine"], f"{rel:.1%}", row["prizePicksAlternateLines"])

Both endpoints are public JSON — no account, no cookies, no proxy, no browser. PrizePicks answers 403 to a filtered request on its main host and 429 to bursts, so requests go to the partner host and get spaced out; a rate limit is retried slowly rather than hammered. My three runs today — 11 league rows, 600 props, 46 comparisons — cost about $0.15 in total, with no per-run fee. The Actor is DFS Player Props API if you want to point it at tonight's slate.

When this is the wrong tool

You want sportsbook odds. Pick'em apps don't publish a moneyline or a vig. For prices across DraftKings, Pinnacle and the like you need an odds feed and a de-vig step — a different tool (this one, in my case).
You want implied probabilities on both apps. PrizePicks publishes a payout type, not a price. There is no honest implied probability to compute from goblin. Quote oddsType for PrizePicks rows and leave the percentage column empty.
You want the whole board, historically. Boards move all day and these endpoints serve now. Schedule the run if you want a time series; nobody will hand you yesterday.
You want picks. This returns a table. It has no opinion.

One run, two boards, one asymmetry worth internalising: Underdog hands you a row per bet, PrizePicks hands you a row per offer. Count rows and you will think PrizePicks has four times the board. It has roughly the same board, sold four ways.

Four Law Firms Published 79 Email Addresses. Four Tech Companies Published 11

Matvey — Fri, 16 Oct 2026 05:11:22 +0000

I run a visa agency in Bali, and the other half of my week goes into Apify Actors. One of them does the thing every sales tool claims to do: you give it Jane Doe, acme.com, it gives you back Jane's work address.

Everybody solves this the same way — apply first.last, because roughly half of corporate mail is first.last, and ship it. That is a coin flip dressed as a lookup. The approach I wanted instead rests on one observation: a company that publishes any personal address on its own website has told you the rule for all of them. If the team page says michael.hart@acme.com, you no longer need to guess what the sales director's address looks like.

So the interesting question stopped being "which format should I guess" and became "how often does a company actually publish something I can read". I ran eight companies through it to find out, and the answer splits so hard by industry that it changes who this kind of tool is for.

The run

Eight people at eight companies, company rows on, four pages read per site:

{
  "people": [
    "Patrick Collison, stripe.com",
    "Jason Fried, basecamp.com",
    "Maria Bennett, cliffordchance.com",
    "Daniel Weber, freshfields.com",
    "Daniel Weber, linklaters.com",
    "Daniel Weber, bakermckenzie.com",
    "Daniel Weber, n8n.io",
    "Daniel Weber, hubspot.com"
  ],
  "candidatesPerPerson": 3,
  "checkMx": true,
  "includeCompanyRows": true,
  "maxPagesPerCompany": 4
}

Two of those names are real people; "Maria Bennett" and "Daniel Weber" are probes I invented, because the person is not what is being measured here. The layout belongs to the company, and the same probe name at eight companies isolates it cleanly. 32 pages, plain HTTP, no browser, no proxy: 7.1 seconds and $0.29 for the whole run on 16 October 2026.

Here is what came back, per company:

Domain	Addresses on site	Usable as evidence	Layout	Confidence
cliffordchance.com	48	22	`first.last`	high
freshfields.com	21	13	`first.last`	high
linklaters.com	10	7	`first.last`	high
bakermckenzie.com	0	0	—	low
n8n.io	6	0	—	low
stripe.com	4	1	`first.last`	medium
basecamp.com	1	1	`first`	confirmed
hubspot.com	0	0	—	low

79 of the 90 published addresses came from the four law firms. 42 of the 44 usable pieces of evidence did too.

That is not a coincidence and it is not about law. Professional services firms publish staff directories because clients need to reach a named partner — and the same is true of agencies, clinics, brokerages, accountants and consultancies. Companies that sell software route everything through a form and a support queue on purpose. Which means: if your lead list is made of firms, this method mostly works. If it is made of SaaS companies, you are back to guessing, and the honest move is to say so in the output rather than to hide it.

90 addresses found, 44 that say anything

The gap between those two columns is where all the work is. An address only counts as evidence if you can tell which half is the first name — and that is harder than it sounds, because jane.diaz@ and complaints-in@ have the identical shape. One token, a separator, one token. A tool that reads shape alone will conclude that Stripe writes firstname-lastname on the strength of a complaints inbox, which is exactly what an early version of mine did.

So every candidate local part is tested against a list of common given names instead:

jane.diaz                    {"shapes":["first.last"],"strength":1}
esther.chancatlin            {"shapes":["first.last"],"strength":1}
victoria.brewertonowen       {"shapes":["first.last"],"strength":1}
jason                        {"shapes":["first"],"strength":1}
complaints-in                {"shapes":[],"strength":0}
nodes                        {"shapes":[],"strength":0}
nlinklaters                  {"shapes":[],"strength":0}
freshfieldsalumninetwork     {"shapes":[],"strength":0}
20iva.celic                  {"shapes":[],"strength":0}
esther.chan2                 {"shapes":[],"strength":0}
anne-marie.nistoroiu         {"shapes":[],"strength":0}

Those are all real locals from this run. A few things worth pointing at:

esther.chancatlin and victoria.brewertonowen pass because the first half is a recognised name — the surname is never checked against anything, which is what lets compound surnames through intact.

20iva.celic is a scraping artifact: a page number glued to an address by the surrounding text. Clifford Chance's site produced both it and the clean iva.celic. The dirty one is refused by a leading-character rule, which is cheap and right. The clean one is also refused, because neither "iva" nor "celic" is in the given-name list — a false negative, and one I am fine with. The site offered 22 other usable addresses. Being wrong about the format is expensive; skipping one address out of 48 costs nothing.

anne-marie.nistoroiu is the one that annoys me. It contains both a dot and a hyphen, the dot wins the split, and anne-marie is not in the name list as a hyphenated token. It should be read as first.last and is not.

nlinklaters@linklaters.com is the kind of thing that makes you add rules you did not plan for: a token that starts with a letter, contains no separator, and is not a name. Read it as initial-plus-surname and you have "N. Linklaters" working at Linklaters.

The output ships patternEvidence and patternEvidenceCount for exactly this reason. 22 agreeing addresses and 1 are both patternSource: "site", and they are not the same claim.

Stripe's one piece of evidence is a placeholder

Stripe published four addresses: dpo@, privacy@, complaints-in@ — all discarded as department mail — and jane.diaz@stripe.com. So the Actor read Stripe's layout off a single address and returned:

{
  "fullName": "Patrick Collison",
  "email": "patrick.collison@stripe.com",
  "emailPattern": "first.last",
  "emailPatternSource": "site",
  "confidence": "medium",
  "patternEvidence": ["jane.diaz@stripe.com"],
  "patternEvidenceCount": 1,
  "emailStatus": "deliverable",
  "emailProvider": "google",
  "emailMxHost": "aspmx.l.google.com",
  "mailboxVerified": false,
  "alternatives": [
    { "email": "patrick@stripe.com", "pattern": "first" },
    { "email": "pcollison@stripe.com", "pattern": "flast" }
  ]
}

Jane Diaz does not work at Stripe. She is a string in the home page's checkout graphic:

payment-graphic.checkout.email-address-us":"jane.diaz@stripe.com"
payment-graphic.checkout.email-address-de":"damian.michelfelder@example.com"
payment-graphic.checkout.email-address-jp":"taro.yamada@example.com"

The German and Japanese variants of the same mockup use @example.com, which any sane filter drops. The US one uses the company's live domain. That slip is the entire reason Stripe has a site layout rather than a default guess.

The answer is probably still correct — first.last is a common layout and Stripe is a large US company. But it is right by luck, and a tool that reported it as "confirmed from the company's website" would be lying with a straight face. medium plus one visible piece of evidence lets you decide. That is the difference between a confidence column that means something and one that is decoration.

While I was in there: Freshfields came back as "companyName": "Leading global law firm". The name falls back through JSON-LD Organization → og:site_name → the first segment of <title>, and Freshfields has neither of the first two, so an SEO title became the company name. Two scraped fields, two reminders that "it parsed" and "it's true" are different states.

What zero evidence looks like

Baker McKenzie and HubSpot published nothing on four pages. n8n published six addresses — marketing@, license@, nodes@, community@, partners@, legal@ — and not one of them says anything about how a person's address is written. "How many addresses did you find" is the wrong metric; "how many contained a human name" is the one that matters.

All three got first.last, patternSource: "default", confidence: "low", and empty patternEvidence. Same shaped answer, honestly labelled as a guess. Sort by confidence and those rows go to the bottom of the sequence, or nowhere.

One more field earns its place here. The four law firms sit behind mail gateways — Mimecast twice, Proofpoint twice — while Stripe, HubSpot and n8n are on Google. emailProvider and emailMxHost come from an MX lookup, which also means mailboxVerified is permanently false: checking whether a specific mailbox exists requires an SMTP conversation on port 25, and outbound 25 is blocked from Apify's cloud for every Actor there, whatever a listing claims. Domain-level truth and published evidence is what is actually obtainable. If you need address hygiene on a list you already have — role flags, disposable domains, deliverability — that is a different job, and Email Verifier & Phone Number Validator is the one I use for it.

Calling it

from apify_client import ApifyClient

client = ApifyClient("<TOKEN>")
run = client.actor("lergassy/email-finder-api").call(run_input={
    "people": ["Daniel Weber, linklaters.com"],
    "includeCompanyRows": True,
})
for row in client.dataset(run["defaultDatasetId"]).iterate_items():
    if row["type"] == "person" and row["confidence"] in ("confirmed", "high"):
        print(row["email"], row["patternEvidenceCount"])

peopleList takes pre-split fields from a CRM export, and inputDatasetId reads the people straight out of another Actor's dataset. Error rows are free, which matters when a third of a real list has an unresolvable company.

When not to use this

If your targets are consumer-facing tech companies, expect mostly low and treat the output as a guess with a mail-server check attached. If you need a confirmed mailbox before sending, no Apify Actor can give you that — send to the confirmed and high rows and let the bounce be the verification, with alternatives as the retry. And if what you actually want is every public address on a set of websites rather than one person's address, this is the wrong shape of tool entirely.

The Actor is Email Finder API. If you find a company whose layout it reads wrongly, the company and the expected address is a genuinely useful bug report — the given-name list and the rules above grew almost entirely out of those. anne-marie.nistoroiu is next.

Every Threads Profile Page Embeds Four Threads: Two Hours of CNN, Seventeen Days of @zuck

Matvey — Thu, 15 Oct 2026 21:16:14 +0000

Half my week is a visa agency in Bali. The other half is Apify Actors, and the newest one is not a scraper but a monitor: you name a few Threads accounts or brand keywords, give the watch a name, put it on a schedule, and every run hands you only the posts it has never handed you before. Same name, same memory, one row per new post.

That shape sounds like a scraper with a Set bolted on, and for about a week I believed it was. The thing that breaks the illusion is a question a scraper never has to ask: how far back does the page I am diffing against actually go?

Because that is the whole game. A monitor compares "what is on the page now" with "what I have already delivered". Anything that fell off the bottom of the page between two checks was never compared to anything. It is not late. It is gone.

All numbers below are from runs I made on 15 October 2026, build 0.1.29, plus one run from 14 October on build 0.1.27. No login, no cookies, no browser — these are the pages Threads serves to a visitor who is not signed in.

Three accounts, one window

I ran the monitor in preview mode (no watch name, nothing remembered) against three accounts, asking for up to 25 posts each. What came back:

Account	Rows	Distinct threads	Oldest → newest row	Depth
`@cnn`	4	4	18:59:07 → 21:00:21 UTC, same day	2.02 hours
`@mosseri`	5	4	2026-10-02 13:32 → 2026-10-12 17:09	10.15 days
`@zuck`	10	4	2026-09-25 16:50 → 2026-10-12 16:56	17.0 days

The row counts are 4, 5 and 10. The thread counts are 4, 4 and 4.

The profile HTML does not embed a number of posts. It embeds four threads, and a thread is one post or a chain of them. @zuck's four threads happen to be 4 + 1 + 4 + 1 posts:

2026-10-12T16:56:29Z  thread=4006434140014576097  pos=0/4
2026-10-12T16:57:09Z  thread=4006434140014576097  pos=1/4
2026-10-12T16:56:28Z  thread=4006434140014576097  pos=2/4
2026-10-12T16:56:28Z  thread=4006434140014576097  pos=3/4
2026-10-12T15:01:17Z  thread=4006376160339141718  pos=0/1
2026-09-28T12:35:32Z  thread=3996155940894885511  pos=0/4
…

@cnn's four threads are four single posts, which is why a news desk that posts all day gives you a two-hour window and a Meta executive who posts twice a week gives you seventeen days. Same markup, same four slots, a 200× difference in what they cover.

Your schedule is in minutes; the window is in threads

This is the part I had wrong when I wrote the first version. I had reasoned about the check interval in the only unit I controlled — minutes — and picked an hour, because most Threads accounts post a few times a day and an hourly check is plainly enough for them.

It is plainly enough for @mosseri. For @cnn the same hour buys you a window with two slots of headroom: the account was running at roughly two posts an hour, four threads deep. A check every three hours against the embedded page alone would have silently skipped posts, and the monitor would have reported nothing wrong, because every post it did see was correctly marked new. Silent, plausible, wrong — the worst failure a scheduled job can have.

The conversion factor between "four threads" and "how long I may sleep" is the account's posting rate, and that is the one variable in the system that belongs to someone else.

The signal that you fell off the end

You cannot know the posts you did not see. But there is a tell, and it is cheap: if every single thread on the page is new to the watch, the page no longer overlaps your memory, and an account that posted exactly four times since the last check is far less likely than an account that posted more.

So the normal check reads one page. Only when the overlap is empty does it ask for the next page of the profile feed:

const gap = !isPreview && !isFirstCheck && rows.length
    && rows.filter((r) => !r.isPinned).every((r) => !seenBefore.has(String(r.id || '')));
if (gap && rows.length < limit && tab?.page_info?.has_next_page && cursor) {
    // one refetch, 25 posts, stop at the first id this watch already delivered
}

Seeded a watch with a memory that deliberately did not overlap and pointed it at @cnn:

INFO  Watch "devto-gap2": 1 post(s) already delivered by earlier runs.
INFO  @cnn: 10 new of 25 checked
INFO  Done: {"checked":1,"newPosts":10,"pages":2,"requests":2,"bytes":1309270}

Two requests instead of one, 25 posts instead of 4. The ten rows it delivered (my maxItems cap) span 5.65 hours; the 25 it read reach back about fourteen hours at that posting rate. A quiet account never triggers this and keeps paying one request per check — which matters when a schedule fires 720 times a month.

Why the cursor is an id and never a timestamp

Look again at @zuck's four rows in feed order:

16:56:29   16:57:09   16:56:28   16:56:28

Not descending. Not ascending. The feed is newest-thread-first, but a thread's own posts come out in reply order, and the author wrote the second link of that chain forty seconds after the first and then back-filled. Store "the newest createdAt I have delivered" as your cursor — the obvious design, the one every incremental-sync tutorial shows you — and the watermark lands at 16:57:09. The two posts at 16:56:28 that follow it in the feed are then older than the watermark, so they are dropped. Two of ten posts lost on a page where nothing went wrong.

The memory is therefore a set of post ids, and the gap scan stops at the first id already in that set rather than at a time. The same rule makes the second page safe: everything after the first familiar id is older than the last check and must not come back as new.

One consequence worth stating plainly: filtered-out posts go into that set too. A post that failed your minLikes floor today has been seen, and should not arrive tomorrow as breaking news because it finally got its tenth like.

The cheapest useful thing a monitor does is refuse to look

A watch will not check the same target more than once an hour. Fire it sooner and it stops before any request:

Watch "devto-demo-15oct" was checked 29 s ago. A watch is checked at most once an hour,
so this run did not look again. Nothing is lost — anything new arrives with the next check.

That run finished in 1.245 seconds, made zero HTTP requests and delivered zero rows. Given the four-thread window, a tighter interval is not obviously wrong — it is what a crisis watch wants — but it has to be a decision, not an accident of someone copying a */5 * * * * cron line.

Calling it

Named watch, two targets, one schedule — the whole thing:

curl -X POST "https://api.apify.com/v2/acts/lergassy~threads-monitor/runs?token=$APIFY_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"watchName":"brand-mentions","usernames":["cnn"],"keywords":["my brand"],"maxPostsPerCheck":25}'

Reuse watchName and every later run returns the difference. Leave it empty and you get a preview that remembers nothing, which is how the three measurements above were taken: Threads Monitor.

When this is the wrong tool

You want history. A monitor's answer to "what did they post in June" is nothing at all. That is a Threads Scraper job — search, full accounts, whole threads, profiles.
You want sub-minute latency. Four threads deep and a once-an-hour floor is not a firehose, and public pages will never be one.
You want your own account's numbers. Reach, impressions, follower demographics — that is the official API, which exists precisely and only for the account you own.
You already have a dedup table you trust. Then you have a monitor; it is just made of a scraper plus your table, and you are paying for the overlap you throw away.

And do not hardcode four. It is a server-side rendering choice that owes me nothing: three accounts, one day, one shape. The heuristic that says "no overlap means read further" survives Meta changing that number. A constant does not.

Basecamp's Home Page Gave Me Two Valid Phone Numbers. Both Were Calendar Day Numbers

Matvey — Thu, 15 Oct 2026 13:12:18 +0000

I run a visa agency in Bali. The other half of my week goes into Apify Actors, and one of them does something that sounds trivial until you try it: you give it a list of websites, it gives you back one row per website with the company's e-mail addresses, phone numbers, socials, contact page and postal address, each contact carrying the page it was found on.

Fetching the pages is the easy part: a business site is a handful of HTML documents and no login. The part that took the most work — and still isn't finished — is that marketing pages are full of contact data that is completely fake and completely well-formed. Not malformed strings you can regex away. Valid E.164 phone numbers. Addresses on the company's own domain that pass a DNS deliverability check.

Here are three of them, from real runs on 13–14 October 2026, all reproducible against the live pages as I write this.

A calendar is ten digits long

basecamp.com, home page only, one page read, 568 ms. Two phone numbers came back:

+1 301 516 1718   fixed_line_or_mobile   source: text
+1 301 213 1415   fixed_line_or_mobile   source: text

Basecamp does not publish a phone number. These came out of the page text, and I only found out where by printing the matched substring instead of the parsed number:

+13015161718  MATCHED=> "30 15 16 17 18"
+13012131415  MATCHED=> "30 12 13 14 15"

Basecamp's home page shows off its calendar view, and that screenshot is not an image — it is rendered HTML. Strip the tags and a month grid collapses into a run of day numbers:

… 29 30 31 Sep 1, 2026 Team Sync 11:00 - 11:30 2 3 Product Meeting 10:00 - 11:00 …

30 12 13 14 15 is ten digits with plausible spacing. I was running candidates through libphonenumber-js, which is the right tool and gave the right answer: in the North American plan, area code 301 (Maryland) with exchange 213 is a valid number. It is a valid number. It is just not anybody's.

My guard against this was a length floor — a number found in prose needs at least seven national digits, so that order IDs and dates don't become phones:

if (source === 'text' && String(pn.nationalNumber).length < 7) return;

Ten digits sails past it. A length floor cannot distinguish a phone number from a calendar, and neither can a numbering-plan validator. The only thing that separates them is where the digits were standing, which is why every phone in the output carries source and sourceUrl:

tel: 4     a tel: link — a human put this here to be dialled
schema.org: 3
whatsapp: 3
text: 1    digits that happened to be shaped like a phone

Rank 1 means "shaped like". Basecamp's real contact on that same page is rank 4 and unambiguous: mailto:jason@basecamp.com.

Stripe's mock checkout, and a filter that fired four times out of five

stripe.com, same run. One e-mail address came back:

{ "email": "jane.diaz@stripe.com", "type": "personal", "isOwnDomain": true,
  "source": "text", "sourceUrl": "https://stripe.com/" }

That is not a Stripe mailbox. Grep the home page for every address on it and the story is immediate:

  2 jane.smith@example.com
  1 taro.yamada@example.com
  1 damian.michelfelder@example.com
  1 billing@example.com
  1 jane.diaz@stripe.com

They all live in one place — the i18n bundle for the mock checkout graphic on the home page:

mkt-ssr.homepage.modular-solutions.payment-graphic.checkout.email-address-us → "jane.diaz@stripe.com"
mkt-ssr.homepage.modular-solutions.payment-graphic.checkout.email-address-de → "damian.michelfelder@example.com"

Whoever wrote the German string used example.com, the domain reserved by RFC 2606 for exactly this. Whoever wrote the US string used stripe.com. My placeholder filter caught four of the five:

const PLACEHOLDER_DOMAIN = new Set(['example.com', 'example.org', 'yourdomain.com', 'test.com', …]);
const PLACEHOLDER_LOCAL  = /^(example|sample|test|yourname|john\.?doe|jane\.?doe|demo|dummy|…)$/i;

jane.doe is in there. jane.diaz is not, and never will be — the list is of placeholder conventions, and a convention nobody agreed on is not detectable.

Then the ranking promoted it. The score is deliberately biased toward the company's own domain, because for lead data that is almost always right:

const emailScore = (e) =>
      (e.isOwnDomain ? 100 : 0) + (e.isFree ? -20 : 0) + e.rank * 5
    + (PRIMARY_LOCAL.has(e.email.split('@')[0]) ? 15 : 0)
    + (e.type === 'personal' ? 4 : 0) + (e.type === 'role' ? 1 : 0);

Here that bias is exactly backwards. The one fake address on the page is the one on stripe.com, so it scores 100 while its four honest siblings have already been dropped, and bestEmail is a person who does not exist.

The deliverability add-on does not save you either:

{ "email": "jane.diaz@stripe.com", "status": "deliverable",
  "provider": "google", "mxHost": "aspmx.l.google.com", "isRole": false }

That verdict is correct and useless at once. A DNS-level check asks whether the domain accepts mail, and stripe.com obviously does. Nothing short of sending mail knows whether the mailbox exists, and I am not doing that from a scraper.

The honest answer for Stripe is in a different run. Pointed straight at https://stripe.com/contact — three pages read, including support.stripe.com — the row came back with zero e-mails and one phone:

{ "domain": "stripe.com", "status": "ok", "emails": [],
  "phones": [{ "phone": "+18889262289", "kind": "toll_free", "source": "text",
               "sourceUrl": "https://stripe.com/contact" }],
  "summary": "Stripe: +18889262289." }

Stripe publishes a support line and no e-mail address. The home page's only "e-mail" is a prop. Both rows are accurate reports of what the page said; only one of them is a contact.

Five real addresses, and the wrong desk wins

Not every miss is fake data. zendesk.com, three pages, five addresses — all of them genuine mailto: links off the contact page:

ask.philippines@zendesk.com   personal   mailto
ask.thailand@zendesk.com      personal   mailto
ask.indonesia@zendesk.com     personal   mailto
ask.malaysia@zendesk.com      personal   mailto
ask.gcr@zendesk.com           personal   mailto

bestEmail is the Philippines desk — for no reason at all, just first in page order among five identical scores. And all five are typed personal, which is wrong: these are regional team mailboxes. The classifier is two lines long:

if (ROLE_PREFIXES.has(l) || ROLE_PREFIXES.has(l.replace(/[._-]/g, ''))) return 'role';
if (/^[a-z]{2,}[._][a-z]{2,}$/.test(l)) return 'personal';   // jane.diaz, j_smith
return 'generic';

ask is in ROLE_PREFIXES. ask.philippines collapses to askphilippines, which is not, so the "two words joined by a dot" rule wins and calls it a person. The same rule is what typed jane.diaz as personal and handed it the +4. Telling a person's name from a department name without a names list is guesswork, and I document it as guesswork rather than pretending otherwise.

Compare apify.com in the same run — four addresses, all role, all mailto, hello@apify.com on top because hello is in PRIMARY_LOCAL. That is what the scoring is built for, and on a site that publishes contacts like a normal business it works.

The other failure mode: nothing at all

Worth saying plainly, because lead-gen tooling rarely does. Out of the big SaaS names I tested, these returned status: "no_contacts" after reading three to six pages each:

monzo.com  notion.com  zapier.com  vercel.com  ycombinator.com  bbc.co.uk

Vercel's row read every door — /contact, /contact/sales, /about — and came back "Vercel: no e-mail or phone; linkedin, facebook, instagram, x, youtube." There is no scraping trick behind that. A company that routes everything through a form and a support portal has no e-mail address to find, and a tool that returns one for them is making it up. Those rows are also free in this Actor — you are billed per website where a contact was actually found, not per website submitted — which is the only honest way to price a job whose hit rate depends on the list.

What I'd tell you to do with the output

Use source as a trust column, not decoration. For cold outreach, keep mailto and schema.org and treat text as a lead to check by hand — every contact ships with sourceUrl, so checking is one click. The same goes for phones: tel is dialled by a human somewhere, text is a pattern match. If you are enriching a CRM rather than mailing, isOwnDomain and isFree matter more, since a sole trader's only address really is on gmail.com.

Calling it is a list of domains and nothing else:

curl -X POST "https://api.apify.com/v2/acts/lergassy~website-contacts-api/run-sync-get-dataset-items?token=$APIFY_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"domains":["basecamp.com","zendesk.com","apify.com"],"maxPagesPerSite":3,"stopEarly":true}'

stopEarly stops reading a site once a page has yielded both an own-domain e-mail and a valid phone — which is why Basecamp's row says pagesScannedCount: 1. Turn it off and you get every address on every page; the price does not change with pages read either way.

The Actor is website-contacts-api on Apify. Where it does not fit: it reads HTML, so a site whose contact block only exists after JavaScript runs will come back thin (the row says so — note: "javascript_rendered_site"); it verifies e-mails at the domain level and never probes a mailbox; and it will not find a person's direct address that the company has not published. It finds what a website publishes, which — as Basecamp's calendar demonstrates — occasionally includes things that merely look published.

Capterra and Software Advice Share One Review Database and Disagree by 13,058 Reviews

Matvey — Thu, 15 Oct 2026 05:12:38 +0000

I run a visa agency in Bali. The half of my week that has nothing to do with visas goes into Apify Actors, and one of them collects B2B software reviews — Capterra, Software Advice, GetApp and TrustRadius — and returns every site with the same field names.

That last part started as a convenience feature — four scrapers, four field vocabularies, one translation layer I got tired of rewriting. What it turned into was a measuring instrument: once the rows line up you can put the sites side by side and see where they disagree. They disagree a lot, and not in the way I expected.

Here is the measurement. Product: Slack. Builds 0.1.39 and 0.1.40, runs on 13–15 October 2026, no proxy.

Three sites, one database, three different totals

Ask for Slack on Capterra, Software Advice and TrustRadius, ten reviews each, and the product header on those rows reads:

source           productReviewCount   productRating   ratingScale
capterra                     11,166          4.4643            5
softwareadvice               24,224          4.6639            5
getapp                       24,224          4.6639            5
trustradius                  10,268               9           10

Software Advice and GetApp agree to four decimal places. Capterra — the biggest brand of the three, the one whose logo everyone recognises — reports 11,166 reviews and an average two tenths of a star lower.

My first guess was that these are simply three separate review pools that happen to overlap in subject matter. That guess is wrong, and the reviewId field is what killed it:

softwareadvice  Capterra___7219769
softwareadvice  Capterra___7224596
getapp          Capterra___7138404
capterra        Capterra___7209002

Those are reviews scraped from softwareadvice.com and getapp.com. They carry Capterra identifiers because all three sites are Gartner properties running on one review database. The IDs interleave, too — 13 of the 20 Software Advice IDs I collected fall inside the numeric range of the 45 Capterra IDs. It is one sequence, handed out to one pool of reviews, served through three front doors with three different filters on the way out.

So the 13,058-review gap is not a data gap. It is an editorial decision about which of the shared reviews each brand chooses to display, and it is invisible if you scrape one site.

The same review, twice, with a different reviewer on it

Across 45 Capterra reviews and 20 Software Advice reviews I caught exactly one ID on both sites: Capterra___7224596. Field by field:

field                     capterra                softwareadvice
title                     "Slack is the best…"    "Slack is the best…"   same
publishedAt               2026-10-04              2026-10-04             same
pros / cons               identical text          identical text         same
overallRating             5                       5                      same
easeOfUseRating           5                       5                      same
functionalityRating       5                       5                      same
valueForMoneyRating       5                       5                      same
customerSupportRating     4                       4                      same
incentivized              true  (NominalGift)     true  (NominalGift)    same
reviewerIndustry          Construction            Construction           same
--
reviewerName              "Chris S."              "Chris S——" (full)     differs
reviewerJobTitle          "General Manager"       null                   differs
reviewerCompanySize       "51-200 employees"      null                   differs
reviewerCompanySizeCode   null                    "D"                    differs
timeUsed                  null                    "More than 2 years"    differs
usageFrequency            null                    "Daily"                differs

Everything a reviewer typed is byte-identical. Everything about the reviewer is split between the two pages. Capterra publishes the job title and a readable company-size range and abbreviates the surname to an initial. Software Advice publishes the reviewer's full first and last name — I'm redacting it here, since the point is the disclosure difference and not this person — drops the job title, and replaces the company-size range with a single letter.

That letter is worth a paragraph of its own. Software Advice and GetApp publish A through I where Capterra publishes 11-50 employees, and neither site publishes a legend. The temptation is to map it yourself: A is surely the smallest bucket, I the largest, nine letters for nine ranges. I didn't, because on this one shared review the letter is D and the range Capterra prints for the same company is 51-200 employees — a single data point, enough to build a guess on and nowhere near enough to ship one. So the Actor passes the letter through in reviewerCompanySizeCode and leaves reviewerCompanySize empty. One confirmed pair is a hint, not a mapping.

What this does to de-duplication

If you are merging Capterra, Software Advice and GetApp, reviewId is a real join key and you should use it. But the merge is not idempotent in either direction, because neither row is a superset of the other. Prefer the Capterra row and you lose usageFrequency and timeUsed. Prefer the Software Advice row and you lose the job title and the human-readable company size. The only correct merge is field-level: for each column, take whichever side is non-null.

TrustRadius stays out of this entirely. Its IDs are slugs with a timestamp — slack-2026-08-05-00-29-43 — its reviewers are its own, and across ten rows it returned zero sub-ratings while filling in reviewerJobTitle on all ten ("Full-stack developer", "Sr. Director engineering", "Senior Salesforce Administrator"). Different site, different database, genuinely additive sample.

And GetApp is no longer a review source in any useful sense. Its product totals are complete and match Software Advice exactly, but the product page now publishes about six short quotes instead of full reviews, with no ratings at all. Of the five rows I got back, three had pros filled and cons empty, two the reverse — the page quotes one half of each review and doesn't say which half. The first one reads "However, managing constant notifications can be overwhelming at times…", which is a complaint, sitting in a field called pros, because that is the only text GetApp published for it. Use GetApp for product-level numbers; don't build a sentiment set from it.

Page one is not a sample

One more thing I only saw because the rows lined up. Ten reviews from each site, in the order the site publishes them, no sort, no filter:

capterra         5 5 3 3 4 5 5 4 4 5     avg 4.3
softwareadvice   5 5 5 5 5 5 5 5 5 5     avg 5.0

Same database. Software Advice's front page was a wall of five stars; Capterra's front page was not. Five of those ten Software Advice reviews were flagged incentivized — NominalGift or VendorReferredIncentivized — against 14 of 45 on Capterra.

The low ratings do exist in the shared pool, they are just not on page one. Asking for them explicitly finds them:

{
  "searchTerms": ["Slack"],
  "searchSites": ["softwareadvice"],
  "maxRating": 3,
  "maxReviews": 10
}

Ten rows: nine 3-star and one 1-star, the oldest from 2025-10-31, six of the ten incentivized. The filter runs while paging rather than after it, so the run keeps reading pages until it has what you asked for or the site runs out:

def matches_filters(row, *, min_rating, max_rating, published_after, published_before):
    # TrustRadius rates out of 10, the Gartner sites out of 5, so filtering happens on
    # the normalized 1-5 value the user is thinking in.
    rating = row.get('normalizedRating', row.get('overallRating'))

That normalization is why maxRating: 3 means the same band of unhappy customers on TrustRadius as on Capterra. overallRating keeps the site's own number, ratingScale says which scale it was, normalizedRating is raw * 5 / scale. A TrustRadius 9 arrives as overallRating: 9, ratingScale: 10, normalizedRating: 4.5, and averaging that against a Capterra 5 is finally a legal operation.

Calling it

Search by name on Software Advice and TrustRadius, by URL on Capterra and GetApp — Capterra's search page refuses automated requests even through a residential proxy, and GetApp publishes no search page at all. Their product pages are served normally, so a URL is all you need:

curl -X POST "https://api.apify.com/v2/acts/lergassy~software-reviews-scraper/run-sync-get-dataset-items?token=$APIFY_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{
    "productUrls": ["https://www.capterra.com/p/135003/Slack/reviews/"],
    "searchTerms": ["Slack"],
    "searchSites": ["trustradius", "softwareadvice"],
    "maxReviews": 200,
    "includeProductRow": true
  }'

Thirty reviews across three sites took 46 seconds; thirty from Capterra alone took 90, because reviews come 25 to a page and each page is a request. Budget roughly three to four seconds per page. The Actor is here if you want to run the comparison on your own category — pricing is per row, $0.0012 a review and $0.003 a product summary, and failed URLs come back as error rows at no charge.

When not to use this

Don't use it to count. If you need "how many reviews does this product have", you now know that question has two different right answers depending on which Gartner brand you ask, and any single number you quote is a brand's choice rather than a fact.

Don't use it for G2 — different site, different gate, not covered here. And if what you want is volume over time, note that publishedAt is reliable but the sites' own ordering is not chronological, so a date histogram needs the full history pulled, not a recent slice.

Do use it when the comparison is the point: the same product across four sites, the same columns, and a normalized rating that makes an average mean something. Just merge field-level, and treat page one as a storefront rather than a sample.

Ten YouTube Comments, One Commenter: What a Reply Budget Does to Your Sample

Matvey — Wed, 14 Oct 2026 21:11:36 +0000

I run a visa agency in Bali. The part of my week that has nothing to do with visas goes into Apify Actors, and one of them pulls YouTube comments — one video, a channel, a playlist, or the top results of a search, one row per comment with likes, reply count, the pinned and hearted flags and the commenter's channel.

People use comment data for sentiment: pull the last twenty videos of a competitor, feed the text to a model, read what their audience actually complains about. That works, and the scraping part is not the hard bit. The hard bit is that two of the three obvious assumptions about a comment sample are wrong, and both of them are wrong quietly — you get a full dataset, the right number of rows, no errors, and a conclusion that isn't about the audience.

Here is the measurement, from runs on 11–14 October 2026, build 0.1.39, no proxy.

One flag, two completely different samples

Same video — jNQXAC9IVRw, "Me at the zoo", the first video on YouTube, 20 years of comments on it. Same limit: 10 comments. Sorted by top. The only difference between the two runs is includeReplies.

With replies off, ten comments from ten different people:

"We're so honored that the first ever YouTube video was filmed here!"   4,800,000 likes
"So we're all here again on October 14th 2026 right"                          746
"Hello"                                                                   303,000
"Is anyone else watching this on a random day in October?"                  1,000
"I'm glad this pops up on my feed every couple years"                         467
"This started it all...... bruh 😳"                                       248,000
"this video lived long enough to see gifs come true"                          459
'Seeing "20 years ago" on a YouTube video makes me feel a certain way'    211,000
'This guys is the only person who has the rights to say "first"'          418,000
"First word on Youtube ever:\nAlright"                                    115,000

With replies on — the default — and the same maxCommentsPerVideo: 10:

isReply  text                                                          likes
false    "We're so honored that the first ever YouTube video was…"  4,800,000
true     "San Diego Zoo That's so awesome! I'm so glad the first…"    206,000
true     "Very cool!"                                                  71,000
true     "cool"                                                        57,000
true     "."                                                           54,000
true     "How did I randomly go to this video and see this comment…"   57,000
true     "Im here before this blows up"                                32,000
true     " @Quetzal_  lol what"                                        17,000
true     "yoo here before thousands of likes"                          18,000
true     "Awesome!"                                                    14,000

One top-level comment and nine replies to it. Ten rows, one conversation, and four of them are a single word or a full stop. Run that through a sentiment model and you have measured one thread on a video with 2.4 million comments.

This is not a bug, and the input field says so in six words — "replies count too when included". It is the interaction that bites. The collector walks the comment list depth-first: take a top-level comment, immediately follow its replies, then move to the next one. Both compete for the same budget:

if (keep(c)) { await pushComment(c, base, null); kept += 1; }
if (includeReplies && c.replyCount && page.replyTokens.has(c.commentId) && kept < wanted) {
    // …up to maxRepliesPerComment replies, each one incrementing the same `kept`
}

The comment at the top of "Me at the zoo" has 985 replies and maxRepliesPerComment defaults to 20. So the first comment plus its reply cap is 21 rows — more than the sample I asked for. The depth-first order is the right default (a thread stays together, and a keyword match inside a thread is still a match), but it means the limit you set is a row budget, not a voice budget.

The arithmetic to set it deliberately:

rows ≈ topLevelComments × (1 + maxRepliesPerComment)

Twenty distinct opinions with their threads at the default reply cap is 420 rows, not 20. If you want breadth, includeReplies: false is the whole fix; the reply count stays on every row, so you still know which comments started something. If you want threads, raise the comment limit by a factor of 21 and expect to pay for it — the Actor bills per comment row, so replies are rows you buy.

Then I ran the identical input four days running

Four runs, 11 to 14 October, same JSON every time: that video, maxCommentsPerVideo: 50, replies on, sort: top. Four datasets of exactly 50 rows.

	Rows	Distinct comments shared with the 14 Oct run
11 Oct	50	21
12 Oct	50	21
13 Oct	50	21
14 Oct	50	—

Across the four runs there are 121 distinct comments, and only 21 appear in all four. Every run returned the same three top-level comments' worth of structure — 3 top-level, 47 replies, the first thread always the 4.8-million-like one — but comments two and three changed almost every day:

11 Oct: "Randomly got recommended this at 11:16 PM…"          3,300 likes
12 Oct: "You will never know why this comment got…"          24,000
13 Oct: 'Seeing "20 years ago" on a YouTube video…'         211,000
14 Oct: "This started it all...... bruh 😳"                  247,000

"Top comments" is a ranking YouTube recomputes, not a stable list, and on a video this size the tail of the top-50 reshuffles daily. The same comment also came back with 417,000 likes on one day and 418,000 on the next, which is the honest behaviour — counts move — but it means a comment is identified by commentId, never by its text plus its like count. If you are tracking a video over time, dedupe on commentId and expect the set to drift under you. If you are sampling once for sentiment, know that you sampled a top-50, not the top-50.

And the dates are arithmetic, not data

YouTube never shows a comment date. It shows an age: "6 years ago", "9 hours ago", "2 days ago". The Actor keeps that string in publishedAgo and also subtracts it from the run clock into publishedAt, because a date column is what every spreadsheet downstream wants. Here is what that does to one comment — the same commentId, five runs:

Run started (UTC)	`publishedAgo`	`publishedAt`
11 Oct 00:33	6 years ago	2020-10-10
12 Oct 21:28	6 years ago	2020-10-12
13 Oct 00:28	6 years ago	2020-10-12
14 Oct 00:45	6 years ago	2020-10-13
14 Oct 21:05	6 years ago	2020-10-14

Two runs on the same calendar day, two different dates, because the subtraction uses the run's clock and a year is 365.25 days. The mapping is not even one-to-one in either direction: the 12 Oct and 13 Oct runs, three hours apart, both landed on 2020-10-12, while the two 14 Oct runs landed a day apart.

The drift is the small problem. The real one is the bucket: "6 years ago" is YouTube rounding down, so the comment's true age is somewhere in [6 years, 7 years). publishedAt: 2020-10-13 is the newest date the comment could have; it could genuinely be from October 2019. For fresh comments the label is tight — "9 hours ago" pins the day — and for anything older than a month it is a floor, not a date. So: filter and group on publishedAgo buckets when the comments are old, use publishedAt for recency windows on fresh comments, and never diff two runs' publishedAt columns and conclude anything.

One more small trap in the same field: an edited comment is labelled "6 years ago (edited)", suffix and all. Across those four runs there were 22 such rows and four distinct label strings — 6 years ago (edited), 5 years ago (edited), 5 months ago (edited), 1 month ago (edited). Matching publishedAgo == "6 years ago" silently drops them. The date parser strips the suffix before doing its arithmetic; a GROUP BY in your sheet does not.

Calling it

One request, and the run-sync endpoint hands back the rows directly — this is the exact call that produced the ten-distinct-commenters sample above:

import requests

rows = requests.post(
    "https://api.apify.com/v2/acts/lergassy~youtube-comments-scraper/run-sync-get-dataset-items",
    params={"token": TOKEN},
    json={
        "videoUrls": ["https://www.youtube.com/watch?v=jNQXAC9IVRw"],
        "maxCommentsPerVideo": 10,
        "includeReplies": False,      # breadth, not one thread
        "sort": "top",
        "language": "en",
    },
).json()

Swap videoUrls for channelUrls, playlistUrls or searchQueries and maxVideosPerSource decides how many videos each source contributes; every row carries source so you know where it came from. The Actor is here: YouTube Comments Scraper.

When not to reach for it. If you need exact comment timestamps, nothing scraped from the watch page will give them to you — the official Data API returns real publishedAt values, at the cost of a key and a daily quota. If you need all comments of a viral video, the arithmetic is unkind: twenty comments per request means 2.4 million comments is 120,000 round trips. And if you want to post, reply or moderate, this is read-only; that is the API's job.

The lesson I keep relearning on other people's data: a limit is only meaningful once you know what the thing being limited is. Ten rows looked like ten opinions right up until I printed the isReply column.

DEV Community: Matvey

I Asked Instagram for NASA's 12 Newest Reels. Nine Belonged to Other Accounts

The setup

The Reels tab is a grid, not an authorship list

The baseline that never formed

Ten identical videos, two different virality answers

The twelve-item ceiling is a scheduling constraint

What the whole exercise cost

When this is the wrong tool

Airbnb Snapped 'Seminyak' to 'Kuta': 90 of 116 Listings Were Labelled Somewhere Else

The place you type is not the place that gets searched

The text label is the wrong filter

It isn't a Bali thing

What to actually do with the rows

When this is the wrong tool

398 of 692 Products Were Published in One Afternoon. Zero Were Created in 90 Days

The measurement

updated_at is worse

What the Actor counts instead

Two caveats, because this is not a law of nature

The fourth store

Calling it

When not to bother

Three of Five Founder Mailboxes Rejected first.last, the Layout Everyone Defaults To

The ranked guess was wrong more often than it was right

Why the default led in all six cases

The budget is two checks, and that's the whole design

Where no amount of check budget helps

The failure that only shows up when you run the same thing twice

Calling it

Allbirds' Home Page Carries No Ad Pixel. Its Tag Container Carries 23 Account IDs

The home page knows nothing

What it does to the output

The cost of the extra fetch

Where this is still wrong, in writing

Calling it

8% of My Capterra Reviews Arrived as the Three Characters $62

How often, and to whom

What $62 actually is

Why a line-based reader misses the rows

The bias is the real damage

After

What to take from this if you scrape Next.js

PrizePicks Gave Me Nine Pass-Yard Lines for One Quarterback. Eight Are Over-Only

The shape problem in one table

Nine rungs, one board number

oddsType and allowedPicks disagree, so read both

Seven of thirty stat names match

What the comparison actually found

Calling it

When this is the wrong tool

Four Law Firms Published 79 Email Addresses. Four Tech Companies Published 11

The run

90 addresses found, 44 that say anything

Stripe's one piece of evidence is a placeholder

What zero evidence looks like

Calling it

When not to use this

Every Threads Profile Page Embeds Four Threads: Two Hours of CNN, Seventeen Days of @zuck

Three accounts, one window

Your schedule is in minutes; the window is in threads

The signal that you fell off the end

Why the cursor is an id and never a timestamp

The cheapest useful thing a monitor does is refuse to look

Calling it

When this is the wrong tool

Basecamp's Home Page Gave Me Two Valid Phone Numbers. Both Were Calendar Day Numbers

A calendar is ten digits long

Stripe's mock checkout, and a filter that fired four times out of five

Five real addresses, and the wrong desk wins

The other failure mode: nothing at all

What I'd tell you to do with the output

Capterra and Software Advice Share One Review Database and Disagree by 13,058 Reviews

Three sites, one database, three different totals

The same review, twice, with a different reviewer on it

What this does to de-duplication

Page one is not a sample

Calling it

When not to use this

Ten YouTube Comments, One Commenter: What a Reply Budget Does to Your Sample

`updated_at` is worse

What `$62` actually is

`oddsType` and `allowedPicks` disagree, so read both