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

  1. Location data

    Grid sample points

  2. Geographic processing

    Bounded, batched lookups

  3. Enrichment

    Google Maps

    Local search

    AI answers

  4. AI analysis

    Structured output

  5. Quality check

    Reported, never substituted

  6. 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
Disclosure
Public product · Private topology and metrics omitted

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

  1. Data
  2. Enrichment
  3. AI analysis
  4. 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

  1. One business, one keyword
    1. Google Maps Position across a geographic grid
    1. Local search results Conventional local listings
    1. Generative AI answers Whether the business is named at all
Each surface answers a different question about the same business, and none of them substitutes for another.

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

  1. Upstream source unavailable
  2. Substitute placeholder or stale value
  3. Report renders as complete
  4. Customer acts on data that was never collected

Implemented

  1. Upstream source unavailable
  2. Failure recorded as a failure
  3. Surfaced in the report
  4. Customer knows what was and was not measured
The left-hand behaviour is the one that destroys trust in a reporting product, and it is invisible until someone acts on a wrong number.

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

  1. Completed scan data
  2. Aggregation across points, keywords and locations
  3. Model analysis Structured, not freeform
  4. Recommendations
  5. Customer-facing report
Analysis consumes completed scans rather than triggering them, so report generation and data collection scale and fail independently.

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.

  1. High-volume geographic lookup
  2. AI Analysis Reports
  3. Google Business Profile automation across its tool surface
  4. Fallback paths for unavailable upstream data
  5. Efficient search and processing
  6. Customer-facing reporting workflows

Why these decisions mattered

The trade-offs behind the work.

  • Report failure honestly

    Decision
    An unavailable upstream source is reported as unavailable.
    Why
    A reporting product that fills gaps with plausible values is worse than one that shows the gap.
  • Analysis as its own service

    Decision
    Recommendation generation runs separately from collection and reporting.
    Why
    Model work and high-volume data collection have different failure modes and different scaling needs.
  • Structured model output

    Decision
    Analysis produces structured results rather than prose.
    Why
    A recommendation that has to be rendered, filtered and compared cannot arrive as a paragraph.
  • Tools over direct API access

    Decision
    The agent acts through declared, validated tools.
    Why
    These tools change a business’s public listing; the model proposes and the runtime decides.
  • Treat each surface separately

    Decision
    Maps, local results and generative answers are distinct sources.
    Why
    Generative visibility has no ranking position; forcing it into one model of rank would misreport it.

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

Next: KEYS Community

Back to all work Start a conversation