Put one buying question to the same AI model on two different occasions and the shortlists it hands back may not match. A vendor named first in one reply can drop to third, or disappear, in the next, and the tone used to describe it can shift as well.
Classic rank tracking is blind to this. It logs the spot a web page holds in a results list for a query. A generated answer has no such list. It is prose that may recommend some brands, put them in an order, describe them warmly or coolly, and send readers to the brand’s own site or to a third party instead.
You will also see this category called an AEO tracking platform, Answer Engine Optimization software, a Generative Engine Optimization platform, or AI search analytics software. The underlying job is AI brand visibility tracking and AI search visibility monitoring that stay trustworthy even though no two answers are identical.
This case study walks through how a platform like this is assembled. The reference product is Lumen | AI Search Visibility Tracker, a self-hosted Laravel application paired with a Flutter mobile app. We follow one measurement from prompt to report, and explain why each part exists, how the parts lean on each other, and where public documentation runs out.
Two terms recur in the text:
- Answer Engine Optimization (AEO): shaping content so AI systems and search features can locate it, interpret it, and cite it when they give a direct answer.
- Generative Engine Optimization (GEO): the same aim, directed at generative models that write answers from retrieved or learned material.
Basis for this write-up. Zipprr reviewed the public CodeCanyon page for Lumen, a tracker sold by EZMatrix (page last updated August 28, 2026; read on October 15, 2026). Nothing beyond that page was examined: no code, no live installation, no customer records, no results data. Every statement carries one of three tags. Documented means the page says so. Recommended design is our own engineering judgment, not a described feature. Not stated means the page does not address the point. Company names such as OpenAI or Google appear only to identify the services involved, and no affiliation or endorsement is implied.
More architecture write-ups are collected in Zipprr’s technical case study library.
Project Overview
| Item | Summary (every row comes from the listing unless marked) |
|---|---|
| Project category | A self-hosted SaaS product that serves many client workspaces, built for tracking brand presence in AI answers, with a Flutter app alongside |
| Core purpose | Shows how often and how favorably a brand surfaces when AI engines answer buyer questions, sets that against rivals, reveals the sites engines lean on, and closes with a prioritized to-do list |
| Supported AI providers | Six services reached through their official APIs: OpenAI, Anthropic, Google, Perplexity, xAI, and DeepSeek. Live web search is switched on wherever a provider offers it |
| Monitoring methodology | A saved prompt set (brand-focused, category-level, head-to-head, and problem-led) goes to the chosen engines several times on a daily or weekly timetable. The repeat count can be adjusted for each engine |
| Analytics capabilities | The share of replies that name the brand, its typical placement, and the tone used, each shown beside the number of samples behind it. Competitor share of voice by engine and across time. A ranking of cited domains with the customer's own site flagged |
| AEO audit capabilities | Scores a site out of 100 on structured data, how answer-ready the content is, the presence of an llms.txt file, and whether AI crawlers can get in. Each failed check comes with an explanation and feeds a sequenced task list |
| SaaS and white-label model | One installation hosts separate client workspaces with team seats and role limits tied to plans. Operators can swap in their own platform name, tagline, logo, favicon, and accent color. Usage runs on credits, Stripe is optional, and provider keys can belong to the operator or to each client. Exports are branded PDF and CSV files |
| Web and mobile access | A browser application plus an iOS and Android Flutter app on the same installation. On launch, the app pulls its branding, sign-up availability, and feature visibility from the server |
| Deployment approach | Self-hosted on Laravel (PHP 8.2 or newer) with MySQL 8 or MariaDB (SQLite only for trials) behind Apache, Nginx, or LiteSpeed. Queue and cache live in the database, with Redis as an option. One cron entry drives schedules, a browser installer handles setup, and a demo mode with sample data needs no API keys |
| Primary intended users | Agencies, consultants, and in-house teams monitoring their own brands and their clients' brands. The page says an Extended License is needed for paid multi-tenant services where other people pay for access |
Evidence scope: the product page only. Wherever this article explains how something could work internally, read it as a design recommendation, not an observation of the product.
The Technical Challenge
Rank tracking reads a position from a stable list. AI answers offer no such list. Each reply is composed on the spot, so the thing being measured can change from one request to the next. The table below separates difficulties that apply across the industry from requirements the listing documents for this platform.
| Challenge | Type | Why it matters |
|---|---|---|
| Same prompt, different replies | General industry | A single reply is one draw from a spread of possible outcomes |
| Providers disagree with each other | General industry | Leading on one engine says little about another |
| Being named is not being cited | General industry | A brand can be mentioned without its site ever being credited |
| Fair comparison needs one method | General industry | Share of voice means little if brands are matched by different rules |
| Screenshots are weak evidence | General industry | One captured reply cannot show that a result repeats |
| Agencies need walled-off client spaces and their own branding | Documented requirement | Client data must stay separate, and reports must carry the agency's identity |
| Numbers must turn into work | Documented requirement | Gaps are converted into a sequenced action list |
| Web and phone must agree | Documented requirement | The Flutter app reads from the same installation as the browser app |
Replies are samples, not rankings
Language models generate text probabilistically, and answer engines may also pull different web sources from one request to the next. Two identical prompts can therefore yield different brand lists.
In practice, one reply is an anecdote. A defensible measurement needs repeated runs and a plain statement of how many sit behind each figure.
Every engine is its own system
Each provider has its own model, its own way of retrieving information, and its own way of exposing sources. Combining them in one dashboard without flattening the differences is an integration problem before it is an analytics problem.
Named versus cited: a four-state visibility ladder
Zipprr uses a simple frame to keep two ideas apart. For any single reply, a brand sits in one of four states:
| State | Brand named in the reply? | Brand's site cited? | Typical reading |
|---|---|---|---|
| Absent | No | No | The reply leaves the brand out entirely |
| Named only | Yes | No | The engine recognizes the brand but credits other sites for what it says |
| Named and cited | Yes | Yes | The strongest case: the reply names the brand and points readers to its own page |
| Cited only | No | Yes | The brand's page fed the reply, yet the brand name never appears |
A tracker that stores only a “mentioned” flag cannot separate these four. The platform’s mention analytics and its citation analysis are what make the difference measurable.
A fair comparison needs one fixed method
Share of voice sets your mentions against competitors’ mentions. That comparison falls apart if brands are matched by different rules, if prompts change between runs, or if engines are sampled unevenly. The method has to be settled before the figures can be trusted.
Agencies need walls and branding
An agency with many clients cannot let one client glimpse another’s prompts, rivals, or results. It also needs reports bearing its own name and colors, not the software vendor’s. The listing describes isolated client workspaces, branding per tenant, and white-label settings.
Measurements must produce work
A dashboard that only reports numbers leaves the hardest step to the reader. The listing describes a sequenced action list built from gaps and audit failures, with a dedicated actions screen on mobile.
Solution Architecture of an AI Search Visibility Tracking SaaS
The platform can be read as one application carrying thirteen responsibilities. The diagram shows how they connect. [D] marks documented components, [R] marks recommended design, and [D, method not stated] marks a documented output whose internal method the page does not describe.
How a single measurement run unfolds
Steps 1, 4, 6, 7, and 8 follow documented behavior. Steps 2, 3, and 5 are design choices we recommend so that the documented behavior stays dependable.
Web application and workspace interface
Documented: the product is a Laravel web application where people register, sign in, and manage a workspace. According to the page, the Flutter app mirrors the workspace screens of the same installation: dashboard, share of voice, prompts, runs, engine answers, cited sources, AEO audits, actions, alerts, reports, team, and billing. Taken together, these make up the AI search monitoring dashboard.
The engine answers screen carries the most architectural weight. It displays each full reply with brands and sources highlighted inside the text, which is the proof layer behind every summary figure.
Recommended design: let every chart open the replies that produced it. When a client asks why a mention rate dipped, the supporting text should be one click away, not a fresh investigation.
Authentication and access control
Documented:
- Self-serve registration and sign-in.
- Password reset that is rate-limited.
- Editable email templates.
- Teams, seats, and roles whose limits depend on the plan.
- Provider API keys held in encrypted form.
- An admin panel covering plans, tenants, and licensing.
Not stated: role names, seat counts, and whether two-factor authentication exists.
Recommended design:
- Keep platform-administrator rights fully apart from workspace rights, so a client manager can never reach tenant management.
- Check each request against the person’s membership in the workspace, not merely against a login.
- Record changes to provider keys, roles, and billing settings.
- Weigh two-factor authentication for agency administrators, who can reach many client workspaces.
Multi-tenant workspace management
Documented: every client receives an isolated workspace with its own branding, all inside a single installation.
Not stated: how that isolation is achieved.
Multi-tenant SaaS architecture generally takes one of two shapes. A shared database with a tenant identifier on each row is simple to deploy and cheap to run. A separate database for each tenant gives firmer separation but demands more operational effort.
Recommended design: on a MySQL or MariaDB deployment, a shared schema with a workspace identifier on every measurement table is the practical fit. It needs automatic query scoping, plus automated tests that try to read another workspace’s data and expect to be refused.
Zipprr’s multi-tenant omnichannel messaging CRM case study looks at multi-tenant design in a different product domain.
Prompt library and measurement orchestration
Documented: a prompt library with four prompt types, prompts that can also be added from the mobile app, competitors named by the user, and runs with batch progress visible in the app.
Each type answers a different question:
- Brand-focused prompts reveal how engines describe the brand when asked about it directly.
- Category-level prompts reveal whether the brand surfaces when a buyer describes a need without naming anyone.
- Head-to-head prompts reveal how the brand fares beside named alternatives.
- Problem-led prompts reveal whether the brand appears when a buyer describes a pain point instead of a product type.
Recommended design: treat a run as a locked plan. If someone edits a prompt or a competitor name next week, last week’s results must not quietly change meaning. Capture the prompt text, engine list, repeat count, and competitor list at the moment a run starts.
AI provider integration layer
Documented: six engines reached through their official APIs, live web search where a provider supports it, encrypted provider keys, and a demo mode that exercises the whole pipeline with no keys and no spend. Operators can either supply the provider keys and sell credits, or have each client bring their own.
This layer is what makes the product a multi-engine AI monitoring system rather than a wrapper around one model. Providers differ in request format, in whether they search the web, and in how they expose sources. Some return a structured source list when searching and nothing when not.
Recommended design:
- Provider adapters: one module per provider that translates the platform’s internal request into that provider’s format and translates the response back. When a provider changes, one adapter changes, not the whole application.
- Capability matrix: a configuration table noting, for each engine, whether it can search the web and whether it returns sources natively.
- Record the conditions: save the model identifier and whether web search was on for every reply. A searching reply and a non-searching reply from the same engine are different measurements.
- Careful retries: a request that timed out may still have been billed, so check its status before sending it again.
A comparable multi-engine design question, applied to image generation, is covered in Zipprr’s multi-engine AI image generator architecture case study.
Repeated sampling and result collection
Documented: the repeat count is adjustable for each engine, and the mention share, typical placement, and tone are reported beside the number of samples behind them.
Not stated: whether every repeat is charged as its own credit, and how long raw replies are kept. The engine answers screen implies replies are stored, but retention is not described.
Sample size is the central reliability control. A standard statistical illustration shows why. It is arithmetic, not product output, and the page does not say which interval method, if any, the product uses:
| Observed | Runs | Approximate 95% Wilson score interval for the true mention rate |
|---|---|---|
| 3 mentions | 5 | about 23% to 88% |
| 30 mentions | 50 | about 46% to 72% |
Both observations equal 60%, yet five runs say almost nothing precise while fifty narrow the range considerably. That is why printing the sample size beside every rate is a sound design choice.
Sampling also drives cost. As a hypothetical, 20 prompts across 4 engines with 5 runs each comes to 400 prompt sends per measurement cycle. If each send is charged as one credit-unit at an engine-specific price, the repeat count becomes a direct spending decision.
Recommended design: store each reply as its own row, with run ID, engine, model, grounding mode, sample index, timestamp, and the parser version that read it. Keeping the parser version lets old replies be re-read if detection rules improve.
For a broader look at multi-model orchestration and credit-based billing in AI products, see Zipprr’s AI SaaS platform architecture guide.
Brand detection and analytics
Documented: mention share, typical placement, and tone for each engine, plus share of voice against competitors the user names, per engine and across time.
This layer performs the AI-generated answer analysis behind brand mention tracking and competitor visibility analysis.
Not stated: how brands are spotted in reply text, how placement is defined, and how tone is classified.
Recommended design:
- Entity dictionary: give each brand its aliases, common misspellings, product names, and domain. Match on word boundaries, and add disambiguation rules for brands whose names are ordinary words.
- A fixed placement rule: decide whether placement means order of first mention or position inside a list, and apply it the same way every time.
- Tone per mention: classify the passage around each mention, not the whole reply. One reply can praise one brand and warn against another.
- Human spot checks: compare automated tone labels with human review from time to time, since tone is the least objective metric here.
Two reading rules follow from the documented metrics:
- AI share of voice is relative to the competitors the user named. Add or remove a rival and the figure moves.
- Typical placement only covers replies where the brand appeared, so read it beside mention share and sample size.
Citation and source analysis
Documented: a cited sources screen, source domains ranked by how often they appear with the user’s own domain highlighted, and sources marked inside the full reply.
This is where the visibility ladder from the technical challenge becomes measurable, and it is the basis of AI citation tracking. The same data answers three separate questions:
- Is our own domain cited, and how often?
- Which competitor domains do engines rely on?
- Which outside domains (review sites, directories, forums, publications) shape replies about this category?
The third group is often the most actionable, because it points to places where visibility can be earned away from your own site.
Recommended design: reduce every URL to its registrable domain, strip tracking parameters, and count a domain once per reply so a long link list does not inflate its frequency. Also note when a reply returned no sources at all, because a non-searching run with no citations does not prove the brand has no influence.
AEO auditing
Documented: a readiness score out of 100 built from four areas: schema markup, answer structure, llms.txt, and crawler access. Failed checks are explained, and gaps flow into the sequenced action list.
Not stated: how the checks are weighted.
This works as an AI search readiness audit for the site itself, separate from what engines say about the brand. The four areas ask practical questions:
- Schema markup: is structured data present and valid?
- Answer structure: do pages open with direct, self-contained answers an engine can lift out?
- llms.txt: does the site publish this optional file for AI systems?
- Crawler access: can AI crawlers fetch the pages, or do robots rules and blocks stop them?
Treat the score as a hygiene check, not a promise. Google states that no special markup or AI-specific text file is needed to appear in its AI features, so an llms.txt result should not be read as a Google ranking lever (Google Search Central). Other AI systems may behave differently.
Recommended design: keep audit results for each URL over time and show them beside the prompts where the brand is missing. That ties an on-page weakness to a measured visibility gap while keeping the link a hypothesis to test, not a proven cause.
Scheduling and background processing
Documented: daily or weekly scheduled runs driven by one cron entry, a queue and cache kept in the database, optional Redis and a realtime server, and batch progress visible in the app.
It is a deliberately modest operating model. One cron entry wakes the scheduler, and queued jobs handle the slow work of calling providers.
Recommended design:
- Dispatch one job for each workspace, prompt, engine, and sample, so a single failure does not discard a whole run.
- Give every job a unique key so a retried job cannot create a duplicate reply or a second charge.
- Reserve credits before a job is queued, commit them once the reply is stored, and release them if the job fails, so concurrent runs cannot spend the same balance.
- Cap concurrency for each provider to stay inside its rate limits.
- Show failed jobs to the operator instead of dropping them, and mark the affected metrics as incomplete.
- Move to Redis as queue volume grows, which the page lists as optional.
Teams extending a Laravel scheduler and queue setup like this often bring in outside Laravel development services.
Alerts and notification delivery
Documented: email and webhook alerts when a metric moves, with editable email templates.
Not stated: which triggers and thresholds exist.
Recommended design:
- Compare against a baseline that accounts for sample size, so a swing from five runs does not raise the same alarm as a swing from fifty.
- Include the engine, the prompt group, the old and new values, and a link to the replies behind the change.
- Sign webhook payloads and retry failed deliveries with backoff, so receiving systems can verify and recover.
- Let each workspace choose its own destinations.
Action management
Documented: gaps become a sequenced action list, the mobile app has an actions screen, and reports end with recommended actions.
Not stated: the ordering logic, the statuses, and any assignment features.
Recommended design: treat an action as a record, not a sentence. A useful one carries its triggering signal (an audit failure, a citation gap, or a competitor leading on a prompt), the evidence behind it, an owner, a status, and a date.
Priority rules should be visible, for instance weighing the size of the gap against the effort to close it. Once an action is marked done, the next scheduled run gives a before-and-after view, shown with sample sizes and without claiming the action caused the change.
Teams that want help carrying out the resulting on-page and content work can pair the platform with hands-on SEO services.
Reporting and exports
Documented: branded PDF and CSV exports that carry the agency’s name and colors, with recommended actions at the end of each report. The white-label name, tagline, logo, favicon, and accent color are editable from the admin panel.
Recommended design:
- Print the run dates, engines, prompt counts, and sample sizes on every report, so a client can see how the figures were produced.
- Apply tenant branding when a report is rendered, not when data is collected, so a rebrand updates future exports without reprocessing history.
- Build PDFs in the background queue, since large reports should not block a web request.
- Keep the CSV close to the stored measurements so analysts can rebuild charts in their own tools.
What cuts across all thirteen components
Three layers sit beside the numbered components: credit-metered billing, the platform administration panel, and the Flutter mobile client. The mobile client is the least duplicated of the three. The page says it reads its branding, sign-up availability, and feature visibility from the server at launch, so a rebrand does not call for a new app build.
For a Flutter mobile app for SaaS products, Zipprr’s AI assistant mobile app case study shows a Flutter client in a different AI product, and its Flutter app development page describes the related service.
