DEV Community: Roberto Kerber

Medimos como 4 marcas aparecem no ChatGPT e no Gemini — os números que encontramos

Roberto Kerber — Fri, 11 Sep 2026 12:20:07 +0000

Trabalhamos com uma pergunta que toda marca vai fazer cedo ou tarde: quando alguém pede uma recomendação ao ChatGPT, ao Gemini ou a outro assistente, a minha marca aparece?

Não é uma pergunta retórica. Assistentes de IA já intermediam decisões de compra — escolher um fornecedor de energia, uma seguradora, uma loja de bricolage. E, diferente do Google, eles não mostram dez links azuis: mostram uma lista curta, com nomes, e pronto. Ou você está na lista, ou você não existe naquela resposta.

Nos últimos meses rodamos auditorias de visibilidade para quatro marcas reais em setores diferentes — energia, seguros, bricolage e agências de marketing. Este post é o que dá para aprender com os números: como medimos, o que os dados mostraram e o que nos surpreendeu (algumas coisas, bastante).

Share of voice: a métrica que importa nas respostas de IA

A métrica central da nossa medição é o share of voice (SoV): de todas as respostas geradas pelos modelos, em quantas a marca aparece espontaneamente, sem qualquer patrocínio ou indução no prompt.

É a versão "answer engine" daquela velha pergunta de SEO ("em que posição estou?"), com uma diferença brutal: no Google você pode estar na página 2 e ainda receber clique. Numa resposta de LLM, estar fora da lista é estar fora.

Como medimos (metodologia completa)

Cada auditoria segue sempre o mesmo desenho:

12 perguntas por idioma, escritas como um consumidor real perguntaria (não como um especialista)
3 modelos de IA distintos, consultados via API (usamos GPT-4o-mini, Llama 3.3 70B e Gemini 2.5 Flash, através do OpenRouter)
2 idiomas por auditoria (na maioria, português de Portugal e português do Brasil)
Contagem: uma resposta "contém a marca" quando o nome aparece espontaneamente no texto; quando a resposta traz uma lista ranqueada, registramos também a posição média em que a marca surge

Exemplos reais de perguntas do template (o {nicho} é substituído pelo segmento):

"Quem são os líderes de mercado em {nicho} na Península Ibérica?"
"Empresas de {nicho} com melhor relação qualidade-preço em Portugal"
"Melhores empresas de {nicho} no mercado brasileiro"
"Quem recomenda para {nicho} em Lisboa?"

E a regra de contagem, sem mistério:

# share of voice = fração de respostas em que a marca aparece sozinha
sov = respostas_com_mencao_espontanea / total_de_respostas

Duas notas honestas de engenharia: pedimos max_tokens baixos e um delay entre prompts para não tomar 429 dos provedores; e um detalhe que aprendemos na prática — se o nome do nicho já contém a palavra "agência" (ex.: "agência de marketing digital"), o template em inglês "Most reliable {nicho} agencies in {pais}" gera frases como "Most reliable agência de marketing digital agencies in the Portuguese market". Funciona, mas soa robótico. Vale validar os prompts gerados antes de rodar o batch.

Os números dos 4 relatórios

Foram 4 auditorias, 4 setores, 293 respostas de IA analisadas ao todo. Cada relatório compara a marca analisada com os concorrentes do segmento.

Marca (segmento)	Share of voice da marca	Concorrente à frente	Gap
Galp (energia)	22,1% (15 de 68 respostas)	EDP — 35,3%	13,2 p.p.
Tranquilidade (seguros)	20,6% (13 de 63)	Allianz — 77,8%	57,2 p.p.
Fullsix (agências de marketing)	7,5% (7 de 93)	VML — 23,7%	16,2 p.p.
Leroy Merlin (bricolage)	81,2% (56 de 69)	— (líder; AKI é 2ª, com 49,3%)	—

Duas marcas aparecem em menos de 1 resposta em 4, num cenário onde o consumidor pergunta "quem são os líderes do mercado?" e o modelo responde com uma lista de nomes. A Fullsix — uma agência que vende marketing digital — aparece em 7,5% das respostas do próprio setor. A Allianz domina o debate de seguros com 77,8%, mais de 3x a Tranquilidade.

Nas três auditorias em pt-PT + pt-BR (Galp, Tranquilidade, Leroy Merlin), a metodologia foi idêntica: 12 perguntas × 3 modelos × 2 idiomas. A Fullsix rodou com 4 modelos e em pt-PT + inglês, num batch de junho (as outras três são de setembro).

O que surpreendeu nos resultados

1. A mesma marca desaparece quando você muda o idioma

Este foi o achado mais forte. Olha o mesmo par de marcas, segmento idêntico, só mudando o idioma da pergunta:

Marca	pt-PT	pt-BR
Galp	42,4%	2,9%
Tranquilidade	40,6%	0,0% (0 de 31 respostas)
Leroy Merlin	82,4%	80,0%
Fullsix	2,2% (pt-PT)	testado em inglês: 12,8%

A Galp pontua 42,4% em português europeu e desaba para 2,9% em português brasileiro (1 menção em 35 respostas). A Tranquilidade pior: zero menções em 31 respostas em pt-BR. Zero. Não é "baixa visibilidade", é ausência completa.

A Leroy Merlin, em contraste, crava ~80% nos dois idiomas. Ou seja: o problema não é "português" em abstrato — é a densidade de conteúdo estruturado que existe sobre a marca em cada mercado. Os modelos de IA herdam o que a web de cada idioma diz sobre você. Se o seu mercado-alvo é o Brasil e você só construiu presença em fontes portuguesas, para o LLM você não tem histórico lá.

2. Ser mencionado não basta — a posição média importa

Registrar "a marca apareceu" esconde metade da história. Quando aparece, em que posição da lista?

Leroy Merlin: posição média 1,7 nas listas de recomendação (aparece quase sempre, e quase sempre primeiro)
Galp: posição média 4,7
Tranquilidade: posição média 6,6
Fullsix: posição média 12,7

Uma marca com 20% de share of voice mas posição média 6,6 está, na prática, competindo por sobras de atenção. Num consumo em mobile, a resposta curta, pouca gente expande a lista. Position, not just presence.

3. O "líder do mercado" segundo a IA pode não ser o que você imagina

Em bricolage, a Leroy Merlin com 81,2% e seus rivais Bricomarché e Bricodepot com 0,0% — literalmente zero menções em 69 respostas. Já no nosso quadro, quem luta pelo segundo lugar é a AKI (49,3%).

Em seguros, o podium da IA é Allianz (77,8%), Fidelidade (44,4%), Zurich (34,9%). Em energia: EDP (35,3%), Iberdrola (33,8%), Endesa (23,5%), Galp (22,1%), Repsol (4,4%).

O ponto: o modelo não mede quota de mercado real — mede consistência de menções no conteúdo que absorveu. Uma marca pode ser forte na vida real e fraca no LLM (é exatamente o caso da Galp em pt-BR). Quem não produz presença textual consistente nos canais que os modelos leem (sites de autoridade, comparativos, diretórios, imprensa) fica de fora da lista, mesmo sendo líder offline.

4. Para o mercado de agências, inglês rende mais que português

A Fullsix apareceu em 12,8% das respostas em inglês contra 2,2% em pt-PT (1 menção em 46 respostas). Faz sentido: o conteúdo global sobre agências de marketing vive majoritariamente em inglês (rankings internacionais, awards, diretórios). É um lembrete de que "GEO" não é só traduzir seu conteúdo — é entender em qual idioma o ecossistema de fontes do seu setor é mais denso, e garantir que a sua menção exista lá.

5. Share of voice só é comparável dentro do mesmo benchmark

Uma lição de medição que virou regra interna: SoV não é um número absoluto universal — ele depende do conjunto de perguntas, dos modelos e do mix de idiomas. Duas medições com benchmarks diferentes não são comparáveis entre si; a evolução que importa é o delta da mesma marca contra si mesma, com o mesmo benchmark repetido ao longo do tempo. É o mesmo princípio de qualquer experimento: fixe o protocolo, meça a variação.

O que fazer com esses números (a parte acionável)

O mais útil de cada relatório não é o número agregado — é a lista de perguntas onde a marca não apareceu. É literalmente um roteiro de conteúdo priorizado por demanda real. O processo que recomendamos a partir dos dados:

Pegue as queries onde você ficou de fora e produza conteúdo que responde diretamente a cada uma (não genérico: a pergunta exata como título/H2 funciona como âncora semântica).
Publique onde os modelos olham: blog técnico próprio, imprensa setorial, diretórios, comparativos de terceiros. Os LLMs tendem a citar fontes com densidade consistente de menções — presença esparsa não acumula.
Trate idioma como canal separado. Se você atua (ou quer atuar) em mais de um mercado, cada idioma precisa da sua própria presença construída. O caso da Tranquilidade (0% em pt-BR) não se resolve com tradução — se resolve existindo conteúdo brasileiro sobre a marca.
Meça posição média, não só menção. Subir da posição 6 para a 3 muda o jogo, mesmo com o mesmo share of voice.
Repita o mesmo benchmark mensalmente. SoV é uma série temporal, não um retrato.

Nenhum desses passos exige orçamento de mídia. Exigem método — e uma régua.

Fechando

A pergunta "minha marca aparece no ChatGPT?" é respondível com dados, não com achismo. E os dados, quando você olha, costumam doer um pouco: três das quatro marcas medidas aparecem em menos de 1 resposta em 4 — e a web que os modelos leem em cada idioma é bem menor do que a que existe.

Foi para esse tipo de medição que construímos o GEO Tracker: ele roda as perguntas contra os modelos, calcula share of voice vs. concorrentes por idioma e devolve a lista de oportunidades (existe um teste gratuito de 3 perguntas, e os relatórios completos custam €49 no plano Essencial e €99 no Completo, com breakdown por concorrente — menciono porque alguém vai perguntar, não é o foco do post).

Se você medir a sua marca — com o nosso produto, com um script próprio ou num notebook à mão — o conselho é um só: estabeleça o benchmark, rode, e trate o número como linha de base. A partir daí, qualquer melhoria de presença vira dado, não opinião.

I scraped 100 Brazilian tech job listings to measure what companies actually pay

Roberto Kerber — Fri, 04 Sep 2026 15:28:12 +0000

If you have ever job-hunted in Brazil, you know the ritual: open a listing, scroll past the requirements, look for the salary, and find nothing. It feels like most postings hide the number. I wanted to know whether that impression survives contact with data, so I pulled 100 listings and counted.

It does. 92 of 100 listings disclosed no salary at all.

The measurement

One query — python, filtered to São Paulo state — on Catho, one of Brazil's largest job boards. 100 listings. Every number below comes from that dataset.

Salary disclosure: 8%

	Count
Listings with a numeric salary	8
Listings with no salary	92

Eight. Out of a hundred. And the eight that do publish a number are mostly not publishing a range — they publish a floor, phrased as "A partir de R$ X" (starting from R$ X).

The disclosed values, sorted:

R$  2.000
R$  2.626
R$  3.333
R$  6.426
R$  6.426
R$  7.000
R$  8.000
R$ 12.000

Median: R$ 6.426. Range: R$ 2.000 to R$ 12.000 — a 6x spread across listings that all matched the same python query.

I want to be careful about what this median means. It is the median of the 8 listings willing to publish a number, not the median of the São Paulo Python market. Those are very different populations, and the second one is not measurable from this data. Treat R$ 6.426 as a data point, not a benchmark.

Contract type: the real surprise

I expected CLT (Brazil's standard employment contract) to dominate. Instead, the largest group states nothing at all:

Contract type	Count
Not stated	46
CLT (Efetivo)	33
Prestador de serviços (PJ)	16
Cooperado	2
Temporário	2
Autônomo	1

Nearly half the listings do not say whether the role is CLT or PJ. For a Brazilian candidate that is a material omission — CLT and PJ differ in taxes, benefits, vacation, and severance. Among the 54 listings that do state it, CLT leads 33 to 16 over PJ, roughly 2:1.

Benefits are disclosed far more often than pay

This is the part I did not expect. Companies that will not tell you the salary will happily list the meal vouchers:

Benefit	Listings
Health insurance	22
Meal voucher (tíquete refeição)	22
Transport voucher	19
Food voucher (tíquete alimentação)	12
Dental insurance	11
Group life insurance	11

22 listings disclose health insurance. Only 8 disclose salary. Benefits appear to be treated as marketing; compensation as negotiation leverage.

Across the sample there were 14 distinct benefit types.

Getting the data

Catho renders search results server-side, so pagination is a plain HTTP fetch — 20 listings per page at /vagas/<role>/?page=N. No headless browser needed.

The detail data is the useful part. Each listing has a JSON endpoint:

curl -s "https://oferta.catho.com.br/offer/38220856/d/j?ipo=42&iapo=1" | jq '.o | {
  title: .t,
  salary: .s,
  salary_text: .sn,
  contract: .ctns[0],
  benefits: .bns
}'

That returns salary as an integer (6426), not a formatted string, plus benefits as a proper array and timestamps in ISO format. Which is why the counting above took minutes instead of an afternoon of regex cleanup.

A caveat for anyone building on this: the field names are single letters (t, s, sn, ld) with no documentation. I mapped them by diffing responses against the rendered page. They could change without notice.

Output shape after normalisation:

{
  "jobId": "38220856",
  "title": "Especialista em Energia",
  "company": "LÍDER BPO",
  "salary": 6426,
  "salaryText": "A partir de R$ 6.000,00",
  "city": "São Paulo",
  "state": "SP",
  "contractType": "CLT (Efetivo)",
  "benefits": ["Assistência médica / Medicina em grupo", "Tíquete refeição"],
  "publishedAt": "2026-09-01T16:07:55",
  "isSponsored": true,
  "url": "https://www.catho.com.br/vagas/especialista-em-energia/38220856"
}

Limits of this sample

Worth stating plainly, because a single query is a narrow window:

One query (python), one state (SP), one day. Different roles and regions will look different.
100 listings is enough to establish that non-disclosure is the norm — 92/100 is not a marginal result — but too small to say anything reliable about salary levels.
The salary median rests on 8 data points. Do not build a compensation model on it.
Catho is one board among several. Gupy, InfoJobs, and LinkedIn may have different disclosure cultures.

The disclosure finding is the robust one here. The salary numbers are illustrative.

If you want to run this yourself

The scraper is on the Apify Store — Catho Jobs Scraper. It handles the pagination and the detail-endpoint mapping, returns the flat JSON above, and is pay-per-use. It is how I pulled the 100 listings in this post.

What I would measure next

The single query is a snapshot; the interesting version is longitudinal. Does disclosure improve over time? Does it differ by seniority — do senior roles hide pay more or less than junior ones? Does it differ between CLT and PJ postings?

Brazil has no salary-transparency law, so any movement would be voluntary. Worth watching whether it happens at all.

If you have measured this on another board, I would like to compare — particularly whether the ~8% disclosure rate holds outside Catho.

I pulled 100 used-car listings from Portugal's largest marketplace — what prices actually look like

Roberto Kerber — Fri, 04 Sep 2026 15:28:02 +0000

If you follow the Portuguese car market — as a buyer, a dealership, or an analyst — you have probably noticed something: there is no FIPE table for Portugal. No central reference price. No official depreciation curve. The market price is whatever people are asking on Standvirtual, and until you pull the live listings, you are guessing.

So I pulled 100 live listings and looked at what the data actually says.

The finding: electric has overtaken diesel on the listing page

I expected diesel to dominate. Portugal has been a diesel country for decades. The measured split says otherwise:

Fuel type	Listings	Share
Eléctrico	35	35%
Diesel	25	25%
Híbrido	19	19%
Gasolina	15	15%
Híbrido Plug-In	6	6%

Electric is the single largest category, and diesel is second. Combined, electrified vehicles (electric + hybrid + plug-in) account for 60 of 100 listings.

Before over-reading this: it is the first page of a nationwide, unfiltered query. Standvirtual sorts by relevance, and newer, higher-margin inventory tends to surface first. Whether this reflects the whole national stock or just what dealers push to the top is not something a single page can settle. What it does show is that electric inventory is abundant enough to fill a third of the front page — which was not true a few years ago.

Prices

Across the 100 listings, after filtering out three entries under €500 that are almost certainly monthly-payment figures rather than sale prices:

	EUR
Minimum	1.500
Median	28.900
Mean	32.548
Maximum	128.900

Median asking price is €28.900 — a number that would look extreme in Brazil and is unremarkable in Portugal. The mean sits well above the median, which is the usual signature of a right-skewed market: a handful of six-figure listings dragging the average up while most inventory clusters lower.

Age and mileage

	Value
Median year	2022
Year range	2005 – 2025
Median mileage	44.804 km
Mileage range	5 – 293.000 km

A median of 2022 with 45.000 km is young for a used-car marketplace. Again, front-page selection effects likely apply.

Transmission

Automatic dominates: 83 of 100 listings, against 17 manual. For a European market with a strong manual tradition, that ratio is striking — and consistent with the electric share, since EVs are single-speed by construction.

Getting the data

Standvirtual runs on the OLX Group platform and serves listings server-side. No headless browser, no proxy, no TLS impersonation. A plain HTTP GET returns the full page.

But there is a trap worth documenting, because I fell into it.

The page ships a schema.org OfferCatalog in ld+json containing every car with clean numeric prices. It is tempting to parse that and join it to the article links by index. Do not. The catalog order does not match the rendered order, and the catalog carries no per-item URL. Joining by index produces records where a "Renault Kangoo" title sits on an MG MG4 URL — silently wrong data that looks fine until you click a link.

The reliable approach is to read each <article> block directly. The markup carries semantic labels next to their values:

import re, html, urllib.request

req = urllib.request.Request(
    "https://www.standvirtual.com/carros",
    headers={"User-Agent": "Mozilla/5.0"},
)
page = urllib.request.urlopen(req).read().decode()

for block in re.findall(r"<article[^>]*>(.*?)</article>", page, re.DOTALL):
    parts = [p.strip() for p in html.unescape(re.sub(r"<[^<]+?>", "|", block)).split("|") if p.strip()]
    fields = {parts[i]: parts[i + 1] for i in range(len(parts) - 1)
              if parts[i] in ("mileage", "fuel_type", "gearbox", "first_registration_year")}
    print(fields)

Two more details that cost me time:

Prices are split by non-breaking spaces and inline tags (21<span> </span>900 EUR), so a naive text split loses them. Read them with a regex against the raw markup.
Some cards render the price client-side only. For those, the ld+json catalog is useful — matched by title, not by index. That fallback took price coverage from 11% to 100%.

Output shape:

{
  "id": "8Q0NET",
  "title": "BMW 740",
  "brand": "BMW",
  "price": 17900,
  "currency": "EUR",
  "year": 2012,
  "mileage": 174005,
  "fuelType": "Diesel",
  "transmission": "Automática",
  "isPromoted": false,
  "url": "https://www.standvirtual.com/carros/anuncio/bmw-740-ver-d-auto-ID8Q0NET.html"
}

All six numeric and categorical fields came back populated for 100/100 listings after the fix.

Limits of this sample

100 listings, one query, one day. No brand filter, no region filter, default sort.
Front-page selection. Relevance sorting is not random sampling. The electric share in particular should be read as "what surfaces first", not "what exists nationally".
Asking prices, not transaction prices. Nobody publishes what Portuguese cars actually sell for.
Three sub-€500 entries were excluded as probable monthly-payment figures; that is a judgement call, not a rule.

If you want to run this yourself

The scraper is on the Apify Store — Standvirtual Scraper. It handles the article parsing, the price fallback, and pagination, and returns the flat JSON above. It is how I pulled the 100 listings in this post.

What I would measure next

A single snapshot cannot show depreciation. The interesting version is the same query run daily: which listings cut their price, by how much, and how long they sit before doing it. Time-on-market plus price-cut magnitude is a far better proxy for real value than any asking-price average — and in a country with no FIPE equivalent, it may be the closest thing available.

If you track the Portuguese or wider European used-car market, I would be curious whether the electric share holds up in your data, or whether I am looking at a front-page artefact.

I measured 100 used-car listings in Brazil with one API call - here is what the data says

Roberto Kerber — Fri, 04 Sep 2026 14:19:54 +0000

If you work with the Brazilian car market - a dealership, a marketplace, a pricing model - you have probably hit the same wall I did: there is no clean public dataset of what cars actually cost right now. FIPE gives you a reference price, not the asking price. And the asking price is what the market is really doing.

So I pulled 100 live listings and looked at the gap.

The finding: the ad price is not the FIPE price, and the spread is the story

Webmotors publishes a fipePercent field on each listing - the asking price as a percentage of the FIPE reference. I pulled 100 listings for a single model search and put that column in a table. The result, measured:

88 of the 100 listings carried a fipePercent. The other 12 leave it empty, which is worth knowing before you build anything that assumes the field is always there.
Median: 101%. Mean: 104%. So the typical ad asks slightly above the FIPE reference - the reference is a floor more often than a ceiling.
55% of listings (48 of 88) ask above 100% of FIPE. Asking over the reference is the norm, not the exception.
The range is enormous: 73% to 156%. That spread - not the average - is the actual finding. Two cars the reference prices identically can be advertised 80 percentage points apart.

That last point is the useful one. A single reference number hides a distribution this wide, and the only way to see it is to pull the live ads and look.

One caveat on my own sample, since it matters: all 100 listings were PJ (dealers), zero PF (private sellers). So I cannot tell you from this data whether dealers price differently than private sellers - I would need a sample that actually contains both. If you have seen that comparison done properly, I would like to read it.

The annoying part: getting the data at all

Webmotors does not hand you a JSON file. Two things get in the way, and it is worth being precise about them because they determine your whole approach.

1. Datacenter IPs get blocked. This is the one that surprises people. The same request that works from your laptop returns 403 from a cloud function:

# from a datacenter IP
$ curl -s -o /dev/null -w "%{http_code}" "https://www.webmotors.com.br/api/search/car?..."
403

# same request, residential IP
200

So the naive "deploy a scraper to a VPS" plan dies immediately. You need residential egress, which means either a proxy budget or your own infrastructure.

2. TLS fingerprinting. Even from a good IP, a plain Python HTTP client gets flagged - the TLS handshake of requests/httpx does not look like a browser. The fix is impersonation:

from curl_cffi import requests

r = requests.get(url, impersonate="chrome", timeout=30)

That single argument is the difference between 403 and 200 more often than people expect.

What clean output looks like

Once through, the data is genuinely good. Prices as integers, not "R$ 89.900" strings:

{
  "title": "MERCEDES-BENZ A 250 2.0 CGI GASOLINA SPORT 7G-DCT",
  "make": "MERCEDES-BENZ",
  "model": "A 250",
  "yearFabrication": "2018",
  "yearModel": 2019,
  "odometer": 77000,
  "transmission": "Automática",
  "price": 170900,
  "sellerType": "PJ",
  "city": "Rio de Janeiro",
  "fipePercent": 102
}

price and odometer as numbers means you can sort, filter and compute the moment the run finishes - no regex cleanup step.

Do it yourself, or don't

If you want to build this: curl_cffi with impersonate="chrome", residential egress, and a parser for the search API. Budget for maintenance - the payload shape changes without warning, and you will not find out until your numbers look wrong.

If you would rather skip that, I maintain a scraper on the Apify Store that does exactly this - Webmotors Scraper. It runs through residential IPs, returns the fields above as flat JSON, and is pay-per-use with no subscription. It is also how I pulled the 100 listings in this post.

What I would look at next

The interesting analysis is not a single snapshot - it is the same query run daily. Price cuts on individual listings are a leading indicator of what a segment is really worth, and they only show up in a time series.

If you are working on something similar in the Brazilian market, I am curious what you are seeing - especially on the FIPE spread by region.

How to Build a Brand Monitoring System for AI Search (2026 Guide)

Roberto Kerber — Tue, 01 Sep 2026 10:19:28 +0000

You've heard about GEO. You know your brand needs to show up in AI search. But where do you actually start?

This guide walks you through building a practical brand monitoring system that checks your visibility across the major AI engines — no expensive tools required (though we'll also show you when it's worth investing in one).

Step 1: Define Your Brand Signals

Before you monitor anything, you need to know what you're looking for:

Exact brand name — "Acme Corp"
Common misspellings — "Acme Corp" vs "Acme Corporation"
Product names — "Acme Analytics", "Acme Pro"
Key people — CEO, founder, spokespersons
Industry keywords — "best CRM for startups", "enterprise monitoring tool"

List these out. This is your monitoring dictionary.

Step 2: Manual Baseline Check (Free)

Start with the simplest approach — manual queries:

Open ChatGPT and ask: "What do you know about [your brand]?"
Open Gemini and ask: "Tell me about [your brand]"
Open Perplexity and ask: "What is [your brand] known for?"
Open Claude and ask: "What are the best [your industry] tools?"

Record the answers. Note:

Does the AI mention your brand at all?
Is the context positive, neutral, or negative?
What sources does the AI cite?
Are your competitors mentioned more prominently?

This baseline takes 30 minutes and tells you 80% of what you need to know.

Step 3: Automated Monitoring (Intermediate)

For ongoing monitoring, you can build a simple scraper:

import requests
import json

# Example: Check Perplexity for brand mentions
def check_perplexity(brand_name):
    headers = {
        "User-Agent": "Mozilla/5.0",
        "Accept": "application/json"
    }
    url = f"https://www.perplexity.ai/search?q={brand_name}"
    response = requests.get(url, headers=headers)
    return response.status_code == 200

This is simplified, but the principle holds. The challenge is that every AI engine has different APIs, rate limits, and response formats — which is exactly why most teams eventually use a dedicated tool.

Step 4: Weekly Reporting

Set up a simple weekly process:

Day	Task
Monday	Manual ChatGPT + Gemini check
Wednesday	Perplexity + Claude check
Friday	Compile report, note changes

Track changes in a spreadsheet. After 4 weeks, you'll have a clear picture of your AI visibility trends.

Step 5: When to Invest in a Tool

You can do manual monitoring for free. But as your brand grows, you'll hit limits:

Manual checks don't scale — 5 minutes per engine x 5 engines x 5 brands = 2+ hours daily
AI models update unpredictably — you can't check every hour
Competitor tracking requires even more time
Alerting — you need to know the moment your brand disappears

This is the gap the GEO Tracker fills. Instead of spending hours on manual checks, you get:

Automated daily scans of all major AI engines
Instant alerts when your visibility changes
Competitor comparison reports
PDF reports ready to share with stakeholders

The Bottom Line

Brand monitoring in AI search is not optional anymore. It's as essential as checking your Google rankings was in 2015.

Start with the manual baseline today. Set up a weekly process. And when you're ready to scale, use a tool that does the heavy lifting for you.

Your brand's AI presence is being shaped right now — whether you're watching or not.

💡 Want to skip the manual work?
Get a comprehensive GEO report in 24 hours, or subscribe to continuous monitoring for real-time brand visibility tracking.

How to Monitor Your Brand in AI Search Engines Daily (Not Just Once)

Roberto Kerber — Tue, 01 Sep 2026 10:07:37 +0000

You ran a GEO report last week. Your brand showed up in ChatGPT and Perplexity. Great.

But what about this week?

Here's the uncomfortable truth about AI search visibility: it changes by the day.

Last month, a client of ours saw their brand mentioned in 4 out of 5 AI engines. Seven days later, they were mentioned in only 2. What changed? Nothing on their end. An AI model had updated its training data, and their competitor's new content had gained more citations.

Why One-Time Reports Aren't Enough

1. AI Models Update Constantly

ChatGPT, Gemini, and Perplexity update their knowledge bases regularly. A citation you earned last month can disappear without warning. Without continuous monitoring, you won't know until you lose traffic.

2. Competitors Are Always Publishing

Your competitors aren't standing still. Every article they publish, every backlink they earn, every mention they get — it all feeds into the AI citation system. One week of silence from you is one week of advantage for them.

3. AI Engines Behave Differently

We've observed that ChatGPT favors different sources than Perplexity, which favors different sources than Gemini. A brand invisible in one might be prominent in another. Daily monitoring across all engines reveals blind spots that periodic checks miss.

What Continuous Monitoring Looks Like

Instead of running a single report, imagine this:

Daily scans of ChatGPT, Gemini, Perplexity, Claude, and Google AI Overviews
Weekly summaries showing trends: up, down, or stable
Alert system when your brand disappears from an engine
Competitor tracking — see who's gaining ground

This is the difference between a snapshot and a surveillance system.

The Cost of Not Monitoring

Let's put numbers on it:

Approach	Visibility	Blind spots	Actionable
One-time report	Single moment	Unknown	Maybe
Monthly check	Once/month	30 days gap	Limited
Daily monitoring	Real-time	None	Immediate

If your brand disappears from ChatGPT's knowledge today, you might not notice for weeks. That's weeks of lost citations, lost trust, and lost revenue.

The GEO Tracker Difference

This is exactly why we built the GEO Tracker with both one-time reports AND continuous monitoring capabilities.

You can start with a single report to establish your baseline — and then upgrade to daily monitoring to track changes in real time.

The platform scans:

ChatGPT — Mentions and citations
Gemini — Google's AI visibility
Perplexity — Citation frequency
Claude — Anthropic's sources
Google AI Overviews — Featured snippet presence

Each scan takes minutes, not hours. The report is delivered as a clean PDF you can share with your team.

Your Next Step

Whether you choose a one-time audit or ongoing monitoring, the important thing is to start. AI search is growing at 10x the rate of traditional search. Every month you wait is a month your competitors build visibility you can't easily catch up to.

Get your baseline today. Then monitor continuously. Your brand's AI presence is too valuable to leave to chance.

💡 Ready to check your brand's AI visibility?
Get your comprehensive GEO report today — or upgrade to continuous monitoring for real-time insights.

SEO vs GEO: Why Traditional Search Optimization Is Dying in 2026

Roberto Kerber — Tue, 01 Sep 2026 09:52:00 +0000

Google processes 8.5 billion searches per day. ChatGPT processes 100 million.

But here's the number that matters: ChatGPT's growth rate is 10x faster than Google's was at the same age.

I'm not saying Google is dying. I'm saying the way people find information is fundamentally changing — and if your SEO strategy hasn't adapted, you're already behind.

The Core Difference

SEO (Old Way)

Optimize for ranking algorithms
Target keywords and backlinks
Win the top 10 blue links
Drive clicks to your site

GEO (New Way)

Optimize for AI understanding
Target topics and authority
Win citations in AI answers
Drive brand visibility everywhere

The old game was about getting the click. The new game is about being the source the AI cites.

Why Traditional SEO Is Failing

1. AI Models Don't "Rank" Pages

When ChatGPT answers a question, it doesn't run a Google-style ranking algorithm. It synthesizes information from multiple sources. The concept of "position #1" doesn't exist in AI search.

2. Zero-Click Answers Are Eating Traffic

Google's AI Overviews already answer questions without requiring a click. Perplexity cites sources inline. ChatGPT generates complete answers. The click-through rate for traditional search results has dropped 30%+ since AI Overviews launched.

3. Authority Is Replacing Keywords

In traditional SEO, you could rank for "best project management software" with good keyword optimization. In GEO, ChatGPT cites sources it trusts — established publications, technical documentation, and consistent publishers. Keywords alone don't build trust.

What Works in 2026

For AI Visibility

Publish consistently on platforms AI models train on (Dev.to, Medium, GitHub, your blog)
Use structured content — clear headings, bullet points, data tables, FAQ sections
Cite your sources — AI models prefer content that itself cites authority
Build cross-platform presence — being mentioned in multiple places increases citation probability

For Brand Authority

Fresh content matters more than ever — AI models prioritize recent sources
Technical depth beats breadth — detailed, specific guides outperform generic overviews
Real data and statistics are gold — AI models love citing specific numbers

The GEO Tracker Solution

We built the GEO Tracker because we saw this shift coming. Instead of guessing whether your brand shows up in AI search, we scan the major AI engines daily and give you a clear picture of your visibility.

The report covers:

ChatGPT visibility — Is your brand mentioned in responses?
Gemini presence — What does Google's AI say about you?
Perplexity citations — How often are you cited?
Claude mentions — Are you in Anthropic's knowledge?
Google AI Overviews — Are you featured in AI-generated snippets?

The Bottom Line

SEO isn't dead. But it's evolving into something different. The brands that win in 2026 will be the ones that optimize for AI understanding, not just search rankings.

If you're still doing SEO the 2023 way, you're competing in a shrinking pool. The future belongs to brands that make themselves citable, authoritative, and visible to the AI engines that are becoming the new front page of the internet.

💡 Want to know if your brand shows up in AI search?
The GEO Tracker analyzes your visibility in ChatGPT, Gemini, Perplexity, Claude, and Google AI Overviews — comprehensive PDF report in 24 hours.

The Rise of GEO: How to Optimize Your Brand for AI Search in 2026

Roberto Kerber — Tue, 01 Sep 2026 09:29:49 +0000

ChatGPT is the new Google. Gemini is the new search bar. Perplexity is rewriting how people find answers.

If your brand isn't showing up in these AI assistants, you're invisible to the fastest-growing segment of internet users. This isn't future speculation — it's happening right now.

Generative Engine Optimization (GEO) is the practice of optimizing your online presence so that AI engines surface your brand when users ask questions about your industry. And in 2026, it's the single most overlooked opportunity in digital marketing.

What Changed?

Traditional SEO optimized for links. You ranked pages based on backlinks, keywords, and domain authority. Google gave you 10 blue links, and the user clicked through.

AI search doesn't work that way.

When a user asks ChatGPT "which brand monitoring tool is best for small businesses", the model:

Reads hundreds of sources
Synthesizes the information
Generates a single conversational answer
Cites the sources it used

The point isn't to rank #1 on a SERP anymore. The point is to be cited by the AI.

The 3 Pillars of GEO

1. Content That AI Understands

AI models love structured, factual content. They prefer:

Clear headings and subheadings
Bullet points and tables
Specific data and statistics
Authoritative citations
FAQ sections with direct answers

Weak: "Our product helps businesses monitor their online presence."
Strong: "According to our 2026 analysis, brands that monitor their AI visibility see a 340% increase in citation rate across ChatGPT, Gemini, and Perplexity."

Specificity beats fluff every time with AI engines.

2. Authority Signals

AI models don't just read your content — they evaluate your authority. Key signals include:

Number and quality of external backlinks
Consistency across multiple platforms (LinkedIn, Medium, Dev.to, your blog)
Brand mentions in reputable publications
Content freshness (regular updates, new articles)
Structured data and schema markup

3. Technical Accessibility

If AI can't crawl it, you don't exist:

Fast page load times (AI bots timeout just like users)
Clean HTML that renders without JavaScript (some AI scrapers struggle with JS-heavy sites)
Clear sitemaps that AI crawlers can navigate
Robots.txt that doesn't block AI user agents

The GEO Tracker Approach

At AztecLab, we built the GEO Tracker to solve exactly this problem. Instead of guessing which AI engines see your brand, we:

Scan ChatGPT, Gemini, Perplexity, Claude, and Google AI Overviews
Collect every mention, citation, and representation of your brand
Analyze sentiment, context, and visibility across all platforms
Deliver a comprehensive PDF report in 24 hours

We started with the problem every business faces: "Are we showing up in AI search?" The answer is rarely what companies expect.

Getting Started with GEO

You don't need a massive budget or a dedicated team. Start with these three steps:

Audit your current AI visibility — Search for your brand name and key products in ChatGPT and Gemini. What shows up?
Fix the gaps — Create content that addresses the specific questions your customers ask. Publish consistently on platforms that AI models trust.
Monitor continuously — AI models change their sources regularly. Last month's citation can disappear next month.

💡 Need to monitor your brand's AI presence?
The GEO Tracker analyzes your company's visibility in ChatGPT, Gemini, Perplexity, Claude, and more — PDF report in 24h.

How to Check Your Brand's Visibility in ChatGPT, Gemini, and Perplexity (2026)

Roberto Kerber — Sat, 29 Aug 2026 08:11:00 +0000

If you have ever typed your company name into ChatGPT, Google Gemini, or Perplexity and wondered "is this really how the world sees us?" — you already know the problem. AI search engines do not show ads, they do not offer a "search console" where you can submit your site, and they definitely do not tell you when or why your brand disappeared from their answers.

This is what people in the industry are starting to call Generative Engine Optimization (GEO) — a set of practices for understanding and improving how your brand shows up in AI-generated search results. Unlike traditional SEO, where Google's ranking factors are reasonably well understood, each AI model is a black box fed by a different mix of training data, real-time search results, and internal ranking signals.

What "visibility" means in the AI era

With Google, you had rankings: position 1 through position 100. You could measure it, graph it, and optimize for it. With AI search, the concept of "visibility" is fundamentally different in three ways:

Attribution is sparse. When ChatGPT lists five product recommendations, only one brand gets named. The other four might as well not exist. There is no "page 2" where you can still be found.

Context matters more than keywords. The same AI model may recommend your business when asked "find me a plumber in Lisbon" but ignore you completely when asked "emergency plumbing services Portugal" — even though the real-world intent is identical. Understanding which phrasing triggers a mention is the core of GEO.

Hallucination is a real risk. Some businesses discover that AI models have fabricated negative information about them — a competitor's review attributed to them, a service they never offered listed as a specialty, or worse, an incorrect address or phone number.

Why manual checking does not scale

You could open each AI tool and type queries manually. For one brand in one language on one model, that takes about 15 minutes. Now multiply by:

6+ AI search engines (ChatGPT, Gemini, Perplexity, Claude, Copilot, Grok)
Multiple query variants per engine
Multiple languages (pt-PT, pt-BR, EN, ES)
Regular monitoring (weekly, not once)

The math lands at 20+ hours per week for a single brand. That is where a GEO tracking tool like GEO Tracker comes in — it automates the query execution across all major AI models and compiles the result into a report you can actually act on.

What the report should contain

If you decide to measure your AI visibility, here is the minimum set of data points worth collecting each week:

For each AI model:

Did our brand appear? (yes/no/partial)
In what context? (recommendation, mention, comparison, list)
Positive, neutral, or negative framing?
Was any incorrect information attributed to us?

Across all models:

Which queries produce the highest mention rate?
Which competitor appears most often across models?
Which language has the best coverage?

What to do with the data

Once you have a baseline, the optimization loop is surprisingly similar to old-school SEO:

Fill gaps — if a model never mentions you, check whether your structured data (Organization + LocalBusiness schema) is correct and crawlable
Reinforce positive signals — when a model already recommends you in one language, publish equivalent content in your other target languages
Correct hallucinations — if a model attributes wrong info to your brand, the fix usually requires updating authoritative sources (your website, Wikipedia, Crunchbase) and waiting for the next training cycle
Track competitors — when a competitor appears where you don't, analyze what signals they have that you lack

Traditional SEO is not dead, but it is no longer the only game in town. Businesses that ignore their AI search presence today will find themselves invisible to an entire generation of users who never click "View all" — they just take the AI's answer and move on.

How to Scrape Google Play for ASO, Keyword & App Data (2026)

Roberto Kerber — Sat, 29 Aug 2026 08:04:48 +0000

If you are trying to scrape Google Play for Android ASO research, keyword tracking, or competitor app data, you already know it is not the same problem as the iOS side: Google does not publish anything close to Apple's iTunes Search API. There is a Play Console Developer API, but it only serves data for apps you own - it will not let you look up a competitor's rating or search for who ranks on a keyword. This post walks through what scraping Google Play actually involves without an official API, and how to get clean structured app data without reverse-engineering a page yourself. Whether you searched "google play scraper", "android aso" or "google play api" to get here, the tradeoffs below apply either way.

Why scraping Google Play is harder than it looks

There is no public, documented API for reading someone else's app data on Google Play. Everything that library authors and scrapers rely on comes from the Play Store's own web page: when you load play.google.com/store/apps/details?id=... in a browser, the rating, install count, and description are not returned as clean JSON from an endpoint - they are embedded inside a <script> tag as a deeply nested array, addressed by numeric position rather than named fields (AF_initDataCallback blobs, in the terminology scraping libraries use for this pattern). There is no schema, no versioning, and no changelog when Google alters it.

That has a few concrete consequences:

Positional, not named, fields. You are not reading app["rating"] - you are reading data[1][2][51][0] and hoping that index still means "rating" after the next Play Store frontend deploy.
Silent breakage. When the blob structure shifts, you don't get an error - you get None or the wrong value in a field that used to work, and nothing tells you which index moved.
Search has no clean equivalent either. The Play Store search results page renders similarly - keyword ranking has to be scraped from the same kind of embedded blob, in results order, with no separate "ranking API" to call.
No official rate limit guidance, because there's no official API. You are making requests against a consumer-facing web page, not a developer product, so there is no documented ceiling - only the point where you start getting blocked or served degraded HTML.

Approach 1: DIY with Python

Attempt 1: plain requests against the app detail page

import requests, re, json

def fetch_playstore_app_raw(package_name: str, country="us", lang="en"):
    url = f"https://play.google.com/store/apps/details?id={package_name}&gl={country}&hl={lang}"
    r = requests.get(url, timeout=10)
    # the app's data lives inside a script tag as a JS array literal,
    # not as a JSON endpoint response
    match = re.search(r"AF_initDataCallback\(({.*?})\);", r.text, re.DOTALL)
    if not match:
        return None
    return match.group(1)  # still needs JS-literal parsing, not just json.loads

This gets you the HTML, but the payload is a JavaScript object literal embedded in a script tag, not valid JSON on its own - you need a parser tolerant of JS syntax, and then you need to know which numeric index in that nested array holds rating, which holds installs, and so on. That mapping is not documented anywhere; it is discovered by diffing known values against the blob and is exactly the part that breaks on a frontend redesign.

Attempt 2: search mode (same problem, ranked results)

def search_playstore_raw(term: str, country="us", lang="en"):
    url = f"https://play.google.com/store/search?q={term}&c=apps&gl={country}&hl={lang}"
    r = requests.get(url, timeout=10)
    match = re.search(r"AF_initDataCallback\(({.*?})\);", r.text, re.DOTALL)
    return match.group(1) if match else None
    # results are embedded in the same positional-array format,
    # in the order the Play Store ranks them for the keyword

Same wall, applied to search: the ranking order is real and useful, but extracting appId, title and developer per result means navigating the same undocumented nested structure, and there is no separate "give me just the ranking" endpoint to fall back on.

The real cost here is the reverse-engineering, not the request itself

A single lookup you can eyeball and fix by hand is fine to hand-roll once. The cost shows up when the blob structure shifts and every app in your pipeline returns wrong or missing fields at the same time, with no error telling you why.

	DIY (reverse-engineered blob parsing)	Managed scraper (API)
Upfront cost	Free (your time)	Pay per result returned
Official API	None exists for third-party app data	N/A - handled regardless
Field mapping	You maintain a positional index map	Comes back as named JSON fields
Breakage on redesign	Silent - wrong values, no error	Maintained on the provider's side
Search ranking	Same blob format, no separate endpoint	Same schema as lookup mode
Cross-platform (+iOS)	A second, unrelated scraper to write	Pairs with an App Store ASO actor on the same model

Neither column is objectively "right." A one-off check on a single app is genuinely fine to hand-parse once, and the snippets above will get you the raw blob. Recurring monitoring across a competitor set is where a silent index shift becomes an expensive surprise.

Approach 2: a ready-made Google Play scraper (API)

This is the part where I show you the shortcut. Google Play Scraper is an Apify actor that does the blob parsing and index mapping for you and returns named, typed JSON fields - no reverse engineering, no proxy, no login.

Input

Field	Type	Description	Example
`mode`	string	`search` (apps by keyword) or `lookup` (apps by package name)	`search`
`term`	string	Keyword to search for (search mode)	`fitness tracker`
`appIds`	array	Android package names to look up (lookup mode)	`["com.whatsapp", "com.spotify.music"]`
`country`	string	Two-letter country code for the storefront	`us`, `br`, `de`
`language`	string	Two-letter language code	`en`, `pt`, `de`
`maxResults`	integer	Max apps to return in search mode (up to 30)	`30`

{
  "mode": "lookup",
  "appIds": ["com.whatsapp", "com.spotify.music"],
  "country": "us",
  "language": "en"
}

Output

A real lookup result for WhatsApp Messenger (com.whatsapp):

{
  "appId": "com.whatsapp",
  "title": "WhatsApp Messenger",
  "score": 4.66,
  "ratings": 237058214,
  "reviews": 1962977,
  "installs": "10,000,000,000+",
  "minInstalls": 10000000000,
  "price": 0,
  "free": true,
  "currency": "USD",
  "genre": "Communication",
  "developer": "WhatsApp LLC",
  "released": "Oct 18, 2010",
  "updated": "Jun 10, 2026",
  "version": "Varies with device",
  "contentRating": "Everyone",
  "adSupported": false,
  "summary": "Simple. Reliable. Private. Message and call for free.",
  "descriptionPreview": "WhatsApp from Meta is a free messaging and video calling app...",
  "icon": "https://play-lh.googleusercontent.com/.../icon.png",
  "url": "https://play.google.com/store/apps/details?id=com.whatsapp"
}

minInstalls comes back as an integer you can sort and filter on directly, instead of parsing "10,000,000,000+" yourself. Search mode returns a lighter subset of these fields, in Play Store ranking order.

Calling it from JavaScript

import { ApifyClient } from 'apify-client';

const client = new ApifyClient({ token: '<YOUR_APIFY_TOKEN>' });

const run = await client.actor('plum_spear/aztec-googleplay-aso').call({
  mode: 'search',
  term: 'fitness tracker',
  country: 'us',
  language: 'en',
  maxResults: 30,
});

const { items } = await client.dataset(run.defaultDatasetId).listItems();
console.log(items.length, 'apps');
console.log(items[0]);

Calling it from Python

from apify_client import ApifyClient

client = ApifyClient("<YOUR_APIFY_TOKEN>")

run = client.actor("plum_spear/aztec-googleplay-aso").call(run_input={
    "mode": "lookup",
    "appIds": ["com.whatsapp", "com.spotify.music"],
    "country": "us",
    "language": "en",
})

for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(item["title"], item["score"], item["minInstalls"])

Calling it from the CLI or plain REST

apify call plum_spear/aztec-googleplay-aso --input '{"mode": "search", "term": "fitness tracker", "country": "us", "maxResults": 30}'

curl "https://api.apify.com/v2/acts/plum_spear~aztec-googleplay-aso/run-sync-get-dataset-items?token=<YOUR_APIFY_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"mode": "lookup", "appIds": ["com.whatsapp"], "country": "us"}'

What people actually build with this

ASO managers run search mode against target keywords to see who currently ranks, then switch to lookup mode to track ratings and install counts of specific competitors over time.
App marketers quantify a category before spending on user acquisition - who dominates a keyword, how big their install base is, and whether the niche skews free or paid.
Market researchers measure category size, pricing distribution, and developer concentration across hundreds of apps for reports and trend analysis.
Indie Android developers validate an app idea against real data - keyword saturation, competitor pricing, install base - before writing a line of code.
Cross-platform teams pair this with an App Store ASO scraper to build one consistent iOS + Android dataset instead of maintaining two unrelated pipelines.

Pricing

Pay-per-event: $0.15 per 1,000 results returned, plus a minimal actor-start event. No subscription, no monthly minimum - you only pay for the app records you actually get. Apify's free monthly platform credits are enough to test a real query before deciding whether it's worth it.

For context: the DIY route above means maintaining a positional index map into an undocumented blob that can shift without notice on any Play Store frontend update. $0.15 per 1,000 named, typed results is a small price for not carrying that maintenance risk yourself, especially once you're tracking more than one or two apps.

Using it from an AI agent (MCP)

If you're wiring this into an agent instead of a script, actors published on Apify, including this one, are reachable through Apify's MCP server, which exposes them as callable tools for MCP-compatible clients. Same mode / term / appIds input, no separate integration to write.

Wrap-up

Scraping a single Google Play app yourself is doable - the snippets above will get you the raw blob, and for a one-off check that's enough. What they won't do on their own is survive the next frontend redesign, or hand you named, typed fields you can pipe straight into a spreadsheet or dashboard without maintaining a positional index map by hand. That gap is what Google Play Scraper on Apify closes: pick a mode, get back clean JSON with rating, installs, price and developer already parsed, priced at $0.15 per 1,000 results with no monthly commitment.

💡 Precisa monitorizar a sua marca nestas plataformas?
O GEO Tracker analisa a presença da sua empresa no ChatGPT, Gemini, Perplexity, Claude e mais — relatório PDF em 24h.

How to Scrape the Apple App Store for ASO & Keyword Research (2026)

Roberto Kerber — Fri, 28 Aug 2026 12:06:00 +0000

If you are trying to scrape the Apple App Store for ASO research, keyword tracking, or competitor monitoring, here is the honest version most posts skip: this one is genuinely easier than most scraping targets, because Apple exposes a public search API and public chart feeds that need no login and no proxy. The real cost isn't getting the data out - it's normalizing three different response shapes (search, lookup, charts) into one schema, handling Apple's undocumented rate limits, and building the scheduling and history layer on top so a snapshot becomes a trend. This post covers both. Whether you searched "app store scraper", "aso tool" or "app store keyword api" to get here, the tradeoffs below apply either way.

Why this is easier than most scrapers, and where it still bites you

Apple's iTunes Search API (itunes.apple.com/search) and the App Store's public RSS chart feeds are unauthenticated, documented (loosely), and return JSON directly - no headless browser, no residential proxy, no client-side rendering to fight. For search-by-keyword and lookup-by-ID, a plain requests.get() gets you real data on the first try. That's the good news, and it's worth saying plainly instead of manufacturing a horror story that isn't there.

Where it still costs you real engineering time:

Undocumented rate limits. Apple does not publish a request-per-minute ceiling for the Search API. Hit it too hard and you start getting empty results or throttled responses with no clear error explaining why - you find the limit by tripping it.
Three different response shapes. Search and lookup return the same iTunes JSON schema, but the RSS chart feeds (topfreeapplications, topgrossingapplications, etc.) come back in a different structure entirely, so "one App Store scraper" is really three code paths you have to keep in sync.
No native ranking history. Every response is a snapshot. Trend detection (a rating that moved, a competitor climbing the charts) only exists if you build the storage and diffing layer yourself - the API gives you no memory.
Country and entity matrix. Multiply keywords by storefronts (us, gb, br, de, ...) and entity types (software, iPadSoftware, macSoftware, ...) and you are running and merging a lot of small requests, not one big one.

Approach 1: DIY with Python

Attempt 1: keyword search and ID lookup (this actually works)

import requests

def search_apps(term: str, country: str = "us", limit: int = 50):
    r = requests.get(
        "https://itunes.apple.com/search",
        params={"term": term, "country": country, "entity": "software", "limit": limit},
        timeout=10,
    )
    return r.json()["results"]

def lookup_apps(app_ids: list[str], country: str = "us"):
    r = requests.get(
        "https://itunes.apple.com/lookup",
        params={"id": ",".join(app_ids), "country": country},
        timeout=10,
    )
    return r.json()["results"]

No proxy, no browser, no anti-bot fight. Run this and you get real ratings, prices and metadata back in one request. The catch shows up once you scale it: run this in a tight loop across many keywords and countries and you start hitting undocumented throttling, with nothing in the response body explaining that you've been rate-limited versus that zero apps genuinely matched.

Attempt 2: Top Charts (a different shape entirely)

def get_top_charts(feed: str = "topfreeapplications", country: str = "us", limit: int = 100):
    url = f"https://itunes.apple.com/{country}/rss/{feed}/limit={limit}/json"
    r = requests.get(url, timeout=10)
    entries = r.json()["feed"]["entry"]
    return [
        {
            "rank": i + 1,
            "id": e["id"]["attributes"]["im:id"],
            "name": e["im:name"]["label"],
            "developer": e["im:artist"]["label"],
        }
        for i, e in enumerate(entries)
    ]

This is a completely different response shape from search/lookup - im:-prefixed field names, a different nesting level, no rating or price data at all (charts feeds give you ranking, not metadata; you have to lookup_apps() afterward if you want ratings for the ranked IDs). Two API surfaces, one mental model you have to build to keep them consistent.

The real cost here isn't fetching data, it's normalizing and remembering it

Because the raw fetch is genuinely free and reliable, DIY is a fair choice for a single check. The cost shows up when you need one consistent schema across modes, historical trend data, and scheduled runs.

	DIY (Python, direct API calls)	Managed scraper (API)
Upfront cost	Free (your time)	Pay per result returned
Fetching data	Genuinely easy - public JSON endpoints	Same endpoints, wrapped for you
Rate limit handling	You find the ceiling by tripping it	Handled on the provider's side
Search / lookup / charts schema	Three shapes you normalize yourself	One consistent output schema
Country x entity matrix	You loop and merge manually	One input, same schema every time
History / scheduling	You build storage + diffing	Native scheduler, append to a dataset

Neither column is objectively "right." A one-off keyword check is genuinely fine to write yourself with the snippets above - that's the point of showing they work. Recurring, cross-country, cross-mode monitoring is where the normalization and scheduling work adds up.

Approach 2: a ready-made App Store ASO scraper (API)

This is the part where I show you the shortcut. App Store Scraper & ASO Tool is an Apify actor that wraps search, lookup and charts behind one input and one output schema, with rate limiting, country handling and dataset history already built in.

Input

Only the fields relevant to your chosen mode are required.

Field	Description	Example
`mode`	`search`, `lookup`, or `charts`	`search`
`term`	Keyword to search for (search mode)	`fitness tracker`
`appIds`	One or more App Store IDs (lookup mode)	`["310633997"]`
`feed`	Chart to fetch (charts mode)	`topfreeapplications`
`entity`	App type (search mode)	`software`
`country`	Two-letter storefront code	`us`, `gb`, `br`
`maxResults`	Maximum results to return (up to 200)	`50`

{
  "mode": "search",
  "term": "fitness tracker",
  "entity": "software",
  "country": "us",
  "maxResults": 50
}

{
  "mode": "charts",
  "feed": "topfreeapplications",
  "country": "gb",
  "maxResults": 100
}

Output

The same shape whether the record came from search, lookup, or charts:

{
  "appId": 389801252,
  "name": "Instagram",
  "developer": "Instagram, Inc.",
  "price": 0.0,
  "currency": "USD",
  "rating": 4.7,
  "ratingCount": 28000000,
  "genre": "Photo & Video",
  "version": "350.1",
  "releaseDate": "2010-10-06T19:12:14Z",
  "updatedDate": "2026-06-10T08:31:00Z",
  "contentRating": "12+",
  "url": "https://apps.apple.com/us/app/id389801252",
  "icon": "https://is1-ssl.mzstatic.com/image/.../512x512bb.jpg",
  "description": "Little moments lead to big friendships..."
}

In charts mode, each record also includes a rank field - so you get ranking and metadata in the same response, no separate lookup call needed.

Calling it from JavaScript

import { ApifyClient } from 'apify-client';

const client = new ApifyClient({ token: '<YOUR_APIFY_TOKEN>' });

const run = await client.actor('plum_spear/aztec-appstore-aso').call({
  mode: 'search',
  term: 'fitness tracker',
  country: 'us',
  maxResults: 50,
});

const { items } = await client.dataset(run.defaultDatasetId).listItems();
console.log(items.length, 'apps');
console.log(items[0]);

Calling it from Python

from apify_client import ApifyClient

client = ApifyClient("<YOUR_APIFY_TOKEN>")

run = client.actor("plum_spear/aztec-appstore-aso").call(run_input={
    "mode": "lookup",
    "appIds": ["389801252", "310633997"],
    "country": "us",
})

for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(item["name"], item["rating"], item["version"])

Calling it from the CLI or plain REST

apify call plum_spear/aztec-appstore-aso --input '{"mode": "charts", "feed": "topfreeapplications", "country": "us", "maxResults": 100}'

curl "https://api.apify.com/v2/acts/plum_spear~aztec-appstore-aso/run-sync-get-dataset-items?token=<YOUR_APIFY_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"mode": "search", "term": "fitness tracker", "country": "us", "maxResults": 50}'

What people actually build with this

ASO managers run search mode against target keywords to see who owns them, then lookup mode on a fixed competitor list to track rating, version and update-date shifts week over week.
App marketers monitor Top Charts daily to catch a rising competitor before it breaks into the top ranks.
Market researchers quantify an entire category in one run - who ranks, how they price, how well they're rated - for sizing studies or reports.
Indie developers validate an app idea by checking how saturated a keyword already is and what the top apps charge, before writing a line of code.
Growth and data teams use it as a building block: scheduled runs feed a data warehouse or alerting pipeline for continuous market monitoring.

Pricing

Pay-per-event: $0.15 per 1,000 results returned, plus a minimal actor-start event. No subscription, no monthly minimum, no hidden proxy costs - you only pay for the app records you actually get. Apify's free monthly platform credits are enough to try a real query before deciding whether it's worth it.

For context: the raw API calls above are free, so a single keyword check is genuinely fine to do yourself. Once you need one schema across search, lookup and charts, plus scheduled history so a snapshot becomes a trend, $0.15 per 1,000 results is a small price for not building and maintaining that normalization layer yourself.

Using it from an AI agent (MCP)

Wrap-up

Pulling raw App Store data yourself is genuinely easy - no proxy, no browser, just public JSON endpoints, and the snippets above will get you there for a one-off check. What they won't do on their own is give you one consistent schema across search, lookup and charts, handle Apple's undocumented rate limits gracefully, or turn a snapshot into a trend over time. That gap is what App Store Scraper & ASO Tool on Apify closes: pick a mode, get back the same clean JSON schema every time, priced at $0.15 per 1,000 results with no monthly commitment.

💡 Precisa monitorizar a sua marca nos assistentes de IA?
O GEO Tracker analisa a presença da sua empresa no ChatGPT, Gemini, Perplexity, Claude e mais — relatório PDF em 24h.

How to Scrape OLX Europe: Classified Ads & Prices Across Markets (2026)

Roberto Kerber — Fri, 28 Aug 2026 09:20:30 +0000

If you are trying to scrape OLX across several European markets - Portugal, Poland, Romania, Bulgaria, Ukraine, Kazakhstan - to monitor prices, generate leads, or compare a category across countries, you already know the problem multiplies with every market you add: it is not one scraper you have to maintain, it is potentially six. This post walks through what a DIY multi-country OLX scraper actually costs you, and how to get clean structured data across all six markets from a single input without maintaining six scrapers. Whether you searched "olx scraper europe" or "olx api" to get here, the tradeoffs below apply either way.

Why scraping OLX across multiple countries is harder than it looks

Each OLX country storefront runs on the same underlying platform (the CDN paths give it away - thumbnails come from apollo.olxcdn.com across markets), which means a scraper built for one country transfers conceptually to the others. In practice that "transfer" is exactly where the work hides.

The listing grid renders client-side, so a plain requests.get() returns an app shell with no ad data in it, in every country - you need a real browser or a way to call the same internal API the page itself calls. Anti-bot protection is applied per market: datacenter IPs get rate-limited or blocked, and you need a residential IP that can actually reach the country storefront you're targeting, not just any residential IP.

Then the parts that look small until you multiply them by six:

Currency and formatting - price shows as "450 €" in Portugal, differently formatted in Polish złoty or Romanian leu; you parse each format or write one parser robust enough for all of them
Category IDs - OLX category taxonomy is not identical across countries, so a categoryId that means "phones" in one market does not necessarily mean the same thing in another
Language - titles, descriptions and category names come back in the local language, which affects any keyword-based filtering you do downstream
Layout drift, per country - a redesign can ship to one storefront before the others, so "it broke" can mean one-sixth of your pipeline silently going empty while the rest keeps working

None of this is hard for a single country. Maintaining it correctly across six, with someone noticing the moment one of them silently breaks, is the actual cost.

Approach 1: DIY with Python

Attempt 1: plain requests (does not work)

import requests

r = requests.get("https://www.olx.pt/ads/q-iphone/")
print(r.status_code, len(r.text))
# 200, but the ad grid is empty in the raw HTML - same story
# on every OLX country storefront, not just Portugal.

Attempt 2: one Playwright scraper, looped over countries

from playwright.sync_api import sync_playwright

OLX_DOMAINS = {
    "pt": "olx.pt", "pl": "olx.pl", "ro": "olx.ro",
    "bg": "olx.bg", "ua": "olx.ua", "kz": "olx.kz",
}

def scrape_olx_country(query, country="pt", max_ads=50):
    domain = OLX_DOMAINS[country]
    listings = []
    with sync_playwright() as p:
        browser = p.chromium.launch(headless=True)
        page = browser.new_page()
        page.goto(f"https://www.{domain}/ads/q-{query}/")
        page.wait_for_selector("[data-cy='l-card']", timeout=15000)

        cards = page.query_selector_all("[data-cy='l-card']")
        for card in cards[:max_ads]:
            title = card.query_selector("h6")
            price_raw = card.query_selector("[data-testid='ad-price']")
            listings.append({
                "title": title.inner_text() if title else None,
                "price_raw": price_raw.inner_text() if price_raw else None,
                "country": country,
            })
        browser.close()
    return listings

def parse_price(price_raw: str) -> float:
    # "450 €" -> 450.0 - written for one currency format,
    # needs testing against every market's actual formatting
    digits = "".join(c for c in price_raw if c.isdigit() or c == ",")
    return float(digits.replace(",", ".")) if digits else 0.0

Selector names above are illustrative. This works for one market at a time, on your own IP, for a small run. Scale it to six countries on a schedule and you now own six IP-blocking surfaces, six selector-drift risks, and a price parser that has to be correct for six currency formats - not one problem, six copies of it.

The real cost of DIY isn't one scraper, it's six of them staying in sync

Pulling a handful of listings from one country once is genuinely fine to hand-roll. The cost shows up when you need consistent, structured coverage across markets, on a schedule.

	DIY (Playwright + your own infra, x6 countries)	Managed scraper (API)
Upfront cost	Free (your time, x6 markets)	Pay per ad returned
JS rendering	You maintain a headless browser per market	Handled for you
IP blocking	Residential proxies routed per country	Already routed through a residential IP
Currency / price parsing	You write and test six formats	Comes back as one typed `price` field
Selector breakage	You detect and fix it per market	Maintained on the provider's side
Cross-country comparison	You normalize schemas yourself	Same schema everywhere, `country` is one field

Neither column is objectively "right." If you need a one-off pull from a single country, the Playwright script above is enough. If you need consistent coverage across several of the six markets, on a schedule, the multiplication is the real cost, not the code.

Approach 2: a ready-made OLX Europe scraper (API)

This is the part where I show you the shortcut. OLX Europe Scraper is an Apify actor that covers all six markets - Portugal, Poland, Romania, Bulgaria, Ukraine, Kazakhstan - from a single input, over a residential IP, with prices already parsed and a consistent schema across countries.

Input

Field	Type	Description	Example
`query`	string	Search keyword to look up on OLX	`iphone`
`country`	string	`pt`, `pl`, `ro`, `bg`, `ua`, or `kz` (default `pt`)	`pt`
`categoryId`	string	Optional OLX category ID to narrow the search	`1953`
`maxAds`	number	Maximum number of ads to scrape (default `100`)	`100`

{
  "query": "iphone",
  "country": "pt",
  "maxAds": 100
}

Change only country to run the identical query against a different market - no separate config, no separate parser.

Output

{
  "id": 1093847562,
  "title": "iPhone 13 128GB Azul - Como Novo",
  "price": 450,
  "priceLabel": "450 €",
  "description": "iPhone 13 em excelente estado, 128GB, com caixa e carregador. Bateria a 92%.",
  "city": "Lisboa",
  "region": "Lisboa",
  "created": "2026-06-19T10:14:00+01:00",
  "refreshed": "2026-06-23T08:02:00+01:00",
  "business": false,
  "category": "Telemóveis",
  "imageCount": 7,
  "thumbnail": "https://apollo.olxcdn.com/v1/files/...",
  "url": "https://www.olx.pt/d/anuncio/..."
}

price is a parsed number in every country's response, priceLabel keeps the original string for display, and business tells professional sellers apart from private ones - the same three fields, same meaning, regardless of which of the six markets the ad came from.

Calling it from JavaScript

import { ApifyClient } from 'apify-client';

const client = new ApifyClient({ token: '<YOUR_APIFY_TOKEN>' });

const run = await client.actor('plum_spear/aztec-olx-eu').call({
  query: 'iphone',
  country: 'pt',
  maxAds: 100,
});

const { items } = await client.dataset(run.defaultDatasetId).listItems();
console.log(items.length, 'ads');
console.log(items[0]);

Calling it from Python

from apify_client import ApifyClient

client = ApifyClient("<YOUR_APIFY_TOKEN>")

run = client.actor("plum_spear/aztec-olx-eu").call(run_input={
    "query": "iphone",
    "country": "pt",
    "maxAds": 100,
})

for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(item["title"], item["price"], item["city"])

Calling it from the CLI or plain REST

apify call plum_spear/aztec-olx-eu --input '{"query": "iphone", "country": "pt", "maxAds": 100}'

curl "https://api.apify.com/v2/acts/plum_spear~aztec-olx-eu/run-sync-get-dataset-items?token=<YOUR_APIFY_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"query": "iphone", "country": "pt", "maxAds": 100}'

What people actually build with this

Price monitoring across markets. Track average, minimum and median price for the same term in several countries and get alerted when a listing drops below your target.
Cross-country market research. Run the same keyword in Portugal, Poland and Romania and compare price spread, ad volume and business-vs-private mix side by side.
Lead generation. Use the business flag plus location fields to build prospecting lists of professional sellers by country.
Cross-border resale and arbitrage. Compare prices for the same item across markets and flip the gap - the numeric price field makes this a direct comparison, not manual guesswork.
Real estate professionals. Scrape apartment, house and land listings by city and region in Poland, Romania, Portugal and beyond.
Car dealers and auto traders. Monitor used-car listings across countries and separate dealer ads from private sellers with the business flag.

Pricing

Pay-per-event: $0.15 per 1,000 ads returned, plus a minimal actor-start event. No subscription, no monthly minimum, and the same price whether you run it against one country or all six. Apify's free monthly platform credits let you test it against a real query before deciding whether it's worth it.

For context: if the DIY route above means standing up and maintaining six country-specific scrapers with six currency parsers, $0.15 per 1,000 ads with one consistent schema is the kind of number that stops being a debate fast, especially once you need more than one market at once.

Using it from an AI agent (MCP)

If you're wiring this into an agent instead of a script, actors published on Apify, including this one, are reachable through Apify's MCP server, which exposes them as callable tools for MCP-compatible clients. Same query / country / maxAds input, no separate integration to write.

Wrap-up

Scraping one OLX country yourself is doable - the Playwright snippet above will get you there for a single market. What gets expensive is doing that six times, keeping six selector sets and six currency parsers alive, and normalizing the results yourself before you can compare countries. That gap is what OLX Europe Scraper on Apify closes: give it a query and a country, get back the same clean schema across all six markets, priced at $0.15 per 1,000 ads with no monthly commitment.

💡 Precisa monitorizar a sua marca nos assistentes de IA?
O GEO Tracker analisa a presença da sua empresa no ChatGPT, Gemini, Perplexity, Claude e mais — relatório PDF em 24h.

DEV Community: Roberto Kerber

Medimos como 4 marcas aparecem no ChatGPT e no Gemini — os números que encontramos

Share of voice: a métrica que importa nas respostas de IA

Como medimos (metodologia completa)

Os números dos 4 relatórios

O que surpreendeu nos resultados

1. A mesma marca desaparece quando você muda o idioma

2. Ser mencionado não basta — a posição média importa

3. O "líder do mercado" segundo a IA pode não ser o que você imagina

4. Para o mercado de agências, inglês rende mais que português

5. Share of voice só é comparável dentro do mesmo benchmark

O que fazer com esses números (a parte acionável)

Fechando

I scraped 100 Brazilian tech job listings to measure what companies actually pay

The measurement

Salary disclosure: 8%

Contract type: the real surprise

Benefits are disclosed far more often than pay

Sponsored listings: 4%

Getting the data

Limits of this sample

If you want to run this yourself

What I would measure next

I pulled 100 used-car listings from Portugal's largest marketplace — what prices actually look like

The finding: electric has overtaken diesel on the listing page

Prices

Age and mileage

Transmission

Getting the data

Limits of this sample

If you want to run this yourself

What I would measure next

I measured 100 used-car listings in Brazil with one API call - here is what the data says

The finding: the ad price is not the FIPE price, and the spread is the story

The annoying part: getting the data at all

What clean output looks like

Do it yourself, or don't

What I would look at next

How to Build a Brand Monitoring System for AI Search (2026 Guide)

Step 1: Define Your Brand Signals

Step 2: Manual Baseline Check (Free)

Step 3: Automated Monitoring (Intermediate)

Step 4: Weekly Reporting

Step 5: When to Invest in a Tool

The Bottom Line

How to Monitor Your Brand in AI Search Engines Daily (Not Just Once)

Why One-Time Reports Aren't Enough

1. AI Models Update Constantly

2. Competitors Are Always Publishing

3. AI Engines Behave Differently

What Continuous Monitoring Looks Like

The Cost of Not Monitoring

The GEO Tracker Difference

Your Next Step

SEO vs GEO: Why Traditional Search Optimization Is Dying in 2026

The Core Difference

SEO (Old Way)

GEO (New Way)

Why Traditional SEO Is Failing

1. AI Models Don't "Rank" Pages

2. Zero-Click Answers Are Eating Traffic

3. Authority Is Replacing Keywords

What Works in 2026

For AI Visibility

For Brand Authority

The GEO Tracker Solution

The Bottom Line

The Rise of GEO: How to Optimize Your Brand for AI Search in 2026

What Changed?

The 3 Pillars of GEO

1. Content That AI Understands

2. Authority Signals

3. Technical Accessibility

The GEO Tracker Approach

Getting Started with GEO

How to Check Your Brand's Visibility in ChatGPT, Gemini, and Perplexity (2026)

What "visibility" means in the AI era

Why manual checking does not scale

What the report should contain

What to do with the data