AI · Local Search Intelligence Case study
Local Falcon
An AI-powered local-search and geographic rank-tracking platform covering Google Maps, local search and generative AI visibility.
AI · Local Search Intelligence
Local Falcon Local Falcon
Full-Stack AI & Platform Engineering
System map · Processing pipeline
Verified proof
- Tens of millions Geographic records
- Reported, not filled An unavailable upstream source
Analysis pipeline
Location data
Grid sample points
Geographic processing
Bounded, batched lookups
Enrichment
Google Maps
Local search
AI answers
AI analysis
Structured output
Quality check
Reported, never substituted
Report
Customer-facing
At location scale
- Access-pattern indexing
- Batch processing
- Bounded queries
- Collection separated from reporting
Engineering
OpenAI · Bright Data · Location intelligence · Automated analysis · Data-quality safeguards
Public product · Private topology and metrics omitted
- Role
- Full-Stack AI & Platform Engineering
- Delivery
- Agent.Press engagement
- Disclosure
- Public product · Private topology and metrics omitted
- Links
- Product website
The problem
What the system had to solve.
High-volume geographic rank tracking needed dependable analysis across Google Maps, local-search results and generative AI platforms.
What I owned
The responsibility behind the work.
Contributed to the high-volume location lookup system, AI Analysis Reports and Google Business Profile automation workflows.
Contributed to the high-volume location lookup system, AI Analysis Reports and Google Business Profile automation workflows, working with location infrastructure containing tens of millions of geographic records. Built lookup and fallback behaviour so an unavailable upstream source is reported as such rather than filled in with placeholder content.
Engineering approach
How it was built.
Worked with location infrastructure containing tens of millions of geographic records, requiring efficient search, processing, reporting and data-quality safeguards, including fallback paths that surface a real upstream failure rather than substituting placeholder content.
Analysis pipeline
- Data
- Enrichment
- AI analysis
- Report
Rank is a function of where you stand
Why this is a data problem before it is an AI problem.
Local search has no single answer. A business ranks differently a street away than it does outside its own front door, so measuring visibility means sampling results across a grid of real geographic points rather than asking once and recording a number.
That turns a reporting product into a high-volume data problem: many points, many keywords, many locations, repeated over time so trends mean something. The infrastructure behind it holds geographic records in the tens of millions.
What makes the query space large
- Many sample points per scan
- Many keywords per business
- Many locations per customer
- Repeated over time for trends
- Across several search surfaces
Every one of those multiplies against the others. Lookup efficiency is not an optimisation here; it decides whether a report can be produced at all.
More than one place to be visible
Maps, local results, and now generative answers.
Visibility used to mean the map pack. It now also means what a generative AI assistant says when asked for a recommendation, which is a different surface with different behaviour and no ranking positions to read. Tracking it means treating each surface as its own source rather than assuming one model of "rank" covers all of them.
Tracked surfaces
- One business, one keyword
- Google Maps Position across a geographic grid
- Local search results Conventional local listings
- Generative AI answers Whether the business is named at all
When an upstream source is unavailable
The most important behaviour in a reporting product.
A reporting platform’s value is that its numbers can be trusted. That makes upstream failure a correctness problem, not a availability problem: if a source cannot be reached, the honest answer is to say so.
The lookup and fallback behaviour reports an unavailable source as unavailable. It does not substitute placeholder content, carry forward a previous value as though it were fresh, or quietly produce a report that looks complete and is not.
Two ways to handle a failed source
Deliberately avoided
- Upstream source unavailable
- Substitute placeholder or stale value
- Report renders as complete
- Customer acts on data that was never collected
Implemented
- Upstream source unavailable
- Failure recorded as a failure
- Surfaced in the report
- Customer knows what was and was not measured
A gap a customer can see is recoverable. A fabricated number they cannot see is not.
AI Analysis Reports
From scan data to something a business can act on.
A grid of positions is evidence, not advice. The analysis service reads completed scans and produces recommendations: what the visibility pattern indicates, which locations and keywords are underperforming, and what could be changed. It runs as its own backend service rather than inside the reporting application.
Analysis pipeline
- Completed scan data
- Aggregation across points, keywords and locations
- Model analysis Structured, not freeform
- Recommendations
- Customer-facing report
Report types the service produces
- AI analysis of visibility scans
- Review analysis across locations
- Local keyword research
- Website SEO audit
An agent over the product’s own APIs
Automation across campaigns and business profiles.
Beyond reporting, an agent surface lets customers operate the product conversationally: run and manage scanning campaigns, read reports, and manage the Google Business Profile information that visibility depends on. It is built on the same agent platform pattern used elsewhere in the engagement — a runtime with a declared tool surface over real APIs.
What the tool surface covers
Local Falcon
- Campaign creation and control
- Report retrieval
- Trend and guard analysis
- Multi-location handling
Google Business Profile
- Business information
- Operating hours
- Services
- Photos
- Customer interactions
A tool surface in the dozens rather than a handful, because the underlying APIs are genuinely wide.
A wide tool surface is a validation problem before it is a capability. Every one of those tools can change a customer’s public business listing, so each is schema-declared and executed by the runtime rather than by the model.
Working at location scale
What tens of millions of records changes.
At this size the ordinary approaches stop working. Lookups have to be indexed for the access patterns that actually occur rather than for the ones the schema suggests, processing has to be batched, and anything per-record that touches a network becomes the dominant cost of the whole operation.
What scale forces
- Access-pattern-driven indexing
- Batch rather than per-record processing
- Bounded queries on every customer-facing path
- Collection separated from reporting
- Data-quality checks that run on the data, not on samples
Engineering scope
What I worked on.
- High-volume geographic lookup
- AI Analysis Reports
- Google Business Profile automation across its tool surface
- Fallback paths for unavailable upstream data
- Efficient search and processing
- Customer-facing reporting workflows
Why these decisions mattered
The trade-offs behind the work.
Report failure honestly
Analysis as its own service
Structured model output
Tools over direct API access
Treat each surface separately
Impact
The verified result.
Supported richer customer reports, dependable automated workflows and location-scale processing.
Technology
The technical surface.
- OpenAI
- Bright Data
- Location intelligence
- High-volume search
- Automated reporting