Monitor competitors with Brand Tracker

Start monitoring a brand

1. 1Open Brand TrackerSearch the shared directory by brand or advertiser name.
2. 2Select the correct resultCheck identity and available activity before monitoring it.
3. 3Choose a folderOrganize by client, niche, market, or research goal.
4. 4Set alerts if usefulEnable new-ad alerts for the brand or its folder.

Use the tracked-brand page

• Review ad counts, longevity, formats, platforms, and other available breakdowns.
• The All, Active, and Inactive insight summaries load from bounded database aggregates, so large tracked libraries do not require the browser to download every landing-page or transcript row. If a summary request fails or exceeds its time limit, the panel shows Retry instead of disappearing.
• Brand cards abbreviate ad totals of 1,000 or more with the same compact format as the Brand Tracker sidebar, such as 1.3K. Hover or focus the brand name to see the month and year tracking began.
• Play hooks from a consistent control and open View all for the full list.
• Open any ad for normal click-to-play video controls, including video cards inside carousels. Insight totals and filtered landing-page summaries are aggregated in the database so large libraries do not need to download every matching row before the panel appears.
• Inspect the newest ads and save useful examples without leaving the page.
• Use notes to capture a private research conclusion for your workspace.

Review landing-page history

Open a tracked brand and choose Landing Pages to see the destinations used by its ads. Each sidebar row shows the number of matching ads and the combined running span from the oldest matching ad start date. The badge uses the same status dot and compact day count as an ad card. Hover it for the start and end details; when any matching ad remains active, End says Still running.

A normal brand refresh reconsiders every landing-page URL observed in that scan. A fresh URL reuses its existing result. Once its check lease is stale, Tartol first compares a provider-free HTTP fingerprint and requests a new capture only when that fingerprint changed. This means landing-page checks follow the tracked brand’s refresh cadence rather than the timestamp shown on an individual screenshot.

When the capture comparison confirms a meaningful page change, Tartol writes a new timestamped desktop and mobile version and preserves every older version. Use the dated timeline above the screenshot to move between captures; the date in that timeline is the capture date. A failed or undecided comparison keeps the previous baseline so a later scan can retry instead of silently accepting the new page as unchanged.

The signed visual history and automatic recapture scheduler are read-only Brand Tracker UI behavior. Public REST and MCP continue to expose the underlying authorized ad and landing-page fields, but intentionally do not expose a separate forced landing-page recapture action or the signed historical screenshot gallery.

Refreshes and delays

Brand Tracker data is collected in the background. By default, refreshes run every 1 day for brands with up to 1,000 active ads, every 2 days for 1,001–2,500, every 3 days for 2,501–5,000, every 4 days for 5,001–9,999, and every 5 days for 10,000 or more. A Tartol super admin can edit, add, or remove any row in Super Admin > Brand Tracker > Brand Tracker Configuration > Schedule. There is no fixed row-count limit, the final remaining row also applies to larger brands, and saved changes apply to the next scheduler cycle.

A new run is queued in the background. Queued runs are polled silently: cards, the sidebar, and brand details show no busy or status visual while waiting. Fetching appears only while the database run status is running. After fetching stops, safe reconciliation continues silently while the brand returns to its normal counts, thumbnails, and updated-time display.

The Brand Tracker landing page loads each card’s counts, recent-change badges, activity summary, and five newest thumbnail candidates together. A workspace-specific saved snapshot appears immediately while Tartol refreshes it in the background. If that refresh times out, Tartol keeps the saved cards visible and shows Retry instead of claiming that the workspace has zero tracked brands.

The in-house Meta collector durably checkpoints each cursor page and can resume an interrupted scan without waiting for a batch threshold. Newly committed ads appear in the brand library immediately while collection, media archival, and analysis continue independently. If pagination fails after making useful progress, Tartol keeps the ads already committed. Because that result is not a verified complete snapshot, Tartol never treats an unseen ad as paused and never creates pause events from it. Meta's reported library-size estimate is an optional lower-bound cross-check: when Meta omits it, a trusted terminal response that explicitly reports no next page still proves the snapshot complete. When present, the estimate is also retained for the configured size-based cadence.

A partial tracked-brand scan does not advance the Last scan timestamp or satisfy adaptive cadence. Tartol pauses further automatic scans for that Meta page and sends one incident-aware operator alert instead of retrying indefinitely. A collection that finished but exhausts its bounded database-finalization retries opens the same circuit and preserves its staged snapshot. After the cause is reviewed, choose Refresh ads to acknowledge the incident; Tartol resumes the staged database reconciliation when possible instead of collecting the page again. A verified complete result clears the pause automatically, while another incomplete result pauses and alerts again.

In-house collection

Exact raw Meta checkpoint responses stay in R2. Postgres stores normalized ad fields plus compact R2 references, avoiding duplicate raw-response writes and reducing primary-database and WAL pressure during parallel scans.

Brand Tracker uses Tartol's in-house Meta collector exclusively. ScrapeCreators is retired: it is not a rollback provider, workers do not load its keys, extension saves do not call it, and its balance cannot affect platform health. Historical provider names and usage rows remain only for audit and cost reporting. The in-house provider and configuration version are frozen when a run starts so configuration changes affect new runs only.

Brand Tracker Configuration opens on Activity, followed by Schedule and Proxy pool. Activity separates Brand status, Orphan status, and Scan history. Brand status shows every tracked page with healthy, failed, not-started, or live scan state, import progress and ETA, analysis progress, last scan, and next scheduled scan. A partial tracked-brand snapshot keeps the last verified complete scan time, moves the page to Attention, pauses automatic cadence, and raises one Telegram operations incident; Refresh ads explicitly resumes that page. Color-coded count pills make attention, scanning, healthy, and not-started groups easy to spot. The table starts with the largest imported libraries first, and every column heading can sort it. Orphan status shows the next scheduled status-only check and the complete check history. Every column can be sorted; Ads checked / planned is the selected run workload, while Due pages and Due ads are the exact total backlog across every currently due orphan page. Complete and Partial are mutually exclusive page counts: Complete means Meta proved the snapshot was exhaustive, while Partial means the finished check was retained without that proof. If a page was retried, Result shows the total attempt count and elapsed wall time, and Recent page checks explains the partial reason. A legacy check that processed nothing is labeled No work instead of Successful. One-time historical catalog imports are excluded from recurring orphan maintenance and show a stable estimated 1–4-day duration until a subscribed scan confirms real timing. Schedule contains a compact Refresh by brand size table and Plan limits; the in-house collector is the only collector, so there is no selector card. Scan history keeps brand scans and orphan checks in separate tabs.

When Orphan Ad Checking is enabled, pages that are no longer tracked but still have already-known active ads use the in-house collector. Orphan checks are status-only, follow the configured adaptive size tier, never import newly discovered ads, and skip per-ad detail enrichment, media downloads, and analysis. Each scheduled orphan check queues every currently due page; there is no daily page-count cap. The durable queue and two global browser slots bound simultaneous work, so excess pages wait for capacity instead of being deferred to another day. An incomplete terminal response receives at most one recovery retry; if the retry is still incomplete, it becomes a safe partial result instead of keeping the batch open. Planned cursor-preserving browser rotations for a large library are continuation work, not failure retries. A partial result can confirm returned ads active but cannot mark missing ads inactive; only a complete snapshot may do that. This internal platform-maintenance queue is intentionally unavailable through the public REST API and MCP actions.

Production collection requires confirmed collection authorization, a separate explicit Production replacement approved confirmation after representative probe testing, and at least one active reusable proxy-pool slot. Direct Google Cloud egress is limited to an explicit local/staging probe, stops after 100 collected ads, and cannot be used for production collection. Tartol atomically reserves the run, reusable proxy session, and one of the two global regional browser slots shared by production and staging before asking Cloud Run to start. A newly queued brand immediately attempts admission, and the minute drain retries queued work and fills unused slots. A proxy is returned to the pool as soon as collection finishes; excess scans wait durably in the queue instead of failing when all proxy slots are busy. Every dispatching reservation remains visually queued; Fetching begins only after the database run status becomes running. If a launch is rejected or its reservation expires before browser startup, Tartol returns it to the queue without advancing the cursor or generation or consuming a collector runtime-failure retry.

The in-house collector durably checkpoints every collected page before continuing. Ads saved by an interrupted or partial run are retained for parity review, but only a verified complete snapshot may reconcile missing ads as inactive. A timeout, block, incomplete cursor stream, or other partial result never pauses an unseen ad or creates a false pause event. Large scans preserve the active generation and opaque Meta cursor, rotate the browser before a long pagination session degrades, prefer a different reusable proxy slot, and continue from the durable cursor after a bounded delay. An ambiguous Meta HTTP 200 response preserves that cursor for a bounded retry on another proxy; only a definitive cursor-invalid response starts an isolated generation from the beginning. Only the generation that proves exact exhaustion can reconcile missing ads. After collection, large groups of confirmed inactive ads are committed in page-indexed, bounded database-only batches. If that reconciliation is interrupted and its checkpoints remain intact, Tartol reopens the same staged run and finishes it without another Meta or proxy collection; after bounded retries are exhausted, automatic cadence pauses and Telegram alerts an operator instead of silently collecting the page again. The Brand status changes from Failed to the recovered final result after completion. Raw R2 checkpoints are retained for 30 days, and database collection-staging rows are pruned after 14 days.

For a production in-house run, every committed checkpoint writes only compact staging rows and coalesces a durable publication cursor. A single bounded materializer publishes those staged pages shortly afterward and creates the first required processing step for every imported ad. This keeps collector checkpoints and heartbeats fast during database pressure, prevents thousands of concurrent scans from publishing at once, and lets excess work wait safely instead of holding locks or failing. Final reconciliation cannot start until every staged page for that generation has been published. The bounded fair dispatcher then controls how many processing jobs start at once. Queued runs and post-collection reconciliation are polled silently and show no busy or status visual on cards, the sidebar, or brand details. Only a collector whose database run status is running visibly shows Fetching. While collection continues, the grid and brand detail views refresh from published rows without a manual reload. Fetching progress says ads imported and can briefly trail collected checkpoints while publication drains. Meta's displayed result total is an estimate and can briefly lag the durable imported count; when it does, Tartol keeps showing the truthful imported count without a stale denominator or a percentage above 100. User-visible Total, Active, and Inactive are imported-row counts, remain internally consistent, and never display a negative inactive value; Meta's separately retained library-size estimate is used only for adaptive refresh cadence. Cards use the provider source URL until background archival finishes. Original creative media is queued separately and streamed by the Cloudflare media-ingest Worker directly into R2 without using the residential proxy or Google Cloud-to-R2 transfer. Progressive publication never marks an unseen ad inactive. It can confirm a returned ad is active, but only the final verified complete snapshot may reconcile missing ads.

Imported ads move through media upload, video transcription when needed, and creative analysis independently of collection. A bounded set-based safety repair recreates the earliest missing step for any eligible ad, so processing coverage does not depend on the scan reaching final reconciliation. In an ad's Creative Targeting section, Queued means this background pipeline is still waiting or working regardless of the ad's age; only an explicit failed state is unavailable. In Super Admin > System Health, Daily brand scrapes remain Running until every asynchronous brand reaches a real complete, partial, failed, or skipped outcome; accepting a Cloud Task or browser job no longer counts as scan completion. Ad processor Waiting includes both database-queued work and work already dispatched to Cloud Tasks but not yet claimed; Running includes only work claimed by a real worker. Throughput is successful processing-step completions per minute over an exact rolling 15-minute window, with the exact rolling 60-minute step count shown for comparison. Completed and ETA values count processing steps, not complete ads, because one ad can require transcription, screenshot, and AI-analysis steps. Drain ETA includes all currently queued and dispatched work. Finish ETA is labeled as a pipeline projection: it adds genuinely running rows and the predictable downstream rows that the active pipeline has not inserted yet. The future-step estimate equals active media-upload rows plus active video media-upload rows plus active transcription rows, and Projected remaining steps adds that estimate to all current waiting and running rows. Other queues keep current-row ETA behavior. Enrichment-rate health measures only ads that are 2–24 hours old, giving the production-safe queue time to finish a normal daily burst; an alert now separates never-started, pending or incomplete, and failed ads. A paused Brand Tracker queue remains visibly degraded, but notification waits for 20 consecutive external probes so a brief intentional mixed-version rollout pause does not page; a stranded pause still does. These platform-wide operational diagnostics are internal-only and are intentionally not exposed by the public REST API or MCP.

The Command Center Overview calendar defaults to All time; selecting another range scopes its business, growth, acquisition, operations, and activity data together. The Command Center loads its Ad processor queue, pipeline, failure, and subscription-eligible analysis counters from one authenticated database snapshot, so a refresh does not fan out into page-by-page count requests as the number of tracked brands grows. Raw completed, failed, canceled, pending, queued, processing, and retry-scheduled Ad processor attempts are retained indefinitely. Automatic queue-history deletion is intentionally disabled; any future archive or retention policy requires a separate explicitly approved migration. The aggregate surface is service-only and intentionally unavailable through the public REST API and MCP.

Super Admin > Command Center > Database is the internal database diagnostic view. It charts recent connection use, query and transaction duration, and Brand Tracker/ad-processing queue pressure; lists current blockers, sanitized slow-query fingerprints, and the largest tables; and turns sustained evidence into specific recommendations. Connection and latency signals count application client sessions only: long-lived Supabase system and Realtime replication backends are excluded, and idle transactions must persist for two seconds before appearing. Copy an AI-ready diagnosis copies the sampled metrics and recommended investigation without secrets. The capacity card is a conservative workload-based estimate with a confidence label and range, not a load-test guarantee. The Supabase upgrade signal requires sustained pressure rather than one spike, and storage guidance becomes exact only when SUPABASE_DATABASE_STORAGE_LIMIT_GB is configured. PostgreSQL statistics do not expose Supabase host CPU or RAM, so the page directs a super admin to Supabase for those charts instead of inventing values. Samples are minute-bucketed, lightweight, retained for 30 days, and identical dashboard requests are coalesced. A stuck or repeatedly failing publication queue alerts through the existing Telegram health pipeline after three consecutive unhealthy probes. This cross-workspace view is restricted to the Tartol super admin and intentionally unavailable through public REST, MCP, and Tartol Agent actions; Tartol Agent can explain where it is and how to interpret it.

Super Admin > Command Center > Expenses shows tracked provider spend for the latest 7, 30, or 90 UTC calendar days and compares it with the immediately preceding window. Use Model, Provider, and Feature to regroup the daily chart; the tables also break spend down by operation. Raw provider usage remains the source of truth, while an internal daily rollup refreshes today and yesterday every minute so the dashboard stays responsive as the ledger grows and reconciles late completions. This platform-wide financial view is restricted to super admins and intentionally unavailable through the public REST API and MCP actions. Tartol Agent can explain where to find it and how its date windows and groupings work, but cannot expose the underlying internal ledger.

In-house media upload, transcription, and AI-analysis jobs share one global Cloud Tasks admission window. Due jobs are interleaved by workspace, collection run, and processing step; future retry times are respected, and concurrent drains cannot claim the same job. Ads remain visible immediately while this enrichment continues. Saved-ad jobs, landing-page screenshots, and other non-collection work keep their existing immediate dispatch paths. If the landing-page capture provider is temporarily unavailable, screenshot work stays queued with a delayed retry instead of being discarded.

Super Admin > Command Center > Unit Economics uses complete database-side aggregates instead of downloading capped raw ad and queue lists. Paid invoices are recognized across their Stripe service period, so an annual charge contributes its monthly share instead of appearing only in the payment month. Tracked provider costs replace only their matching fallback coverage; unrelated tracked and modeled dollars are never compared with a maximum or subtracted from one another. Historical ScrapeCreators cost is reported only for old ScrapeCreators production runs; current Brand Tracker collection is in-house. R2 rent accrues as estimated GB-months for time stored, while upload operations remain tracked separately. Ad Processor compute matches the deployed 1 vCPU, 2 GiB, request-concurrency-2 service and conservatively uses full instance seconds per job because actual overlap is not yet measured. The old fixed Ad Processor, Artifact Registry, and R2 placeholders are removed. Shared fixed costs are allocated across the full customer population before plan or user filters, and identical requests are coalesced for 60 seconds. The response explicitly reports a complete database aggregate with no 50,000-row raw-table cutoff. This platform-wide financial view is internal-only and intentionally excluded from the public REST API and MCP actions.

Expanded proxy rows show the current Decodo endpoint, available session slots, and its compact usage summary. Aggregate traffic cards and the collection-run diagnostics panel are intentionally omitted from the configuration page. Facebook documents and GraphQL remain on the residential proxy. Allowlisted public Meta CDN assets bypass it and arrive as free Google Cloud ingress; direct CDN bypass bytes and requests remain available to internal monitoring. Tartol records observed proxy traffic and an estimate with a 25% transport safety margin for internal cost reporting only; those counters never pause or block collection. Once direct pagination owns a validated cursor, Tartol suppresses the duplicate native UI pagination XHR so each remaining page crosses the proxy once; unrelated XHR and beacon traffic is blocked after bootstrap. Eligible country and EU detail lookups reuse the same session as exact-ID GraphQL requests without loading creative media. The collector blocks full creative CDN transfers in the browser while retaining every normalized image, video, thumbnail, and carousel source URL. Video duration is decoded from signed URL metadata without fetching the video body. Original media supplied on Tartol's supported Meta CDN hosts therefore uses neither the residential proxy nor Google Cloud-to-R2 transfer: a private authenticated Cloudflare media-ingest Worker validates the signed URL and every redirect and streams the file directly into R2. Google Cloud receives only stored-object metadata and can read the archived object back from R2 for thumbnail, storyboard, or analysis work; R2 delivery has no egress fee and Google Cloud ingress is free. Small derivatives generated in Google Cloud can still be uploaded to R2 and use metered transfer; full creative bodies do not. A non-CDN or unsupported source remains on Tartol's existing SSRF-protected ingestion path.

Production in-house scans attempt every detail-eligible ad admitted in each browser segment, then checkpoint that segment's detail work before an intentional browser rotation. Detail coverage remains separate from list completeness: a runtime limit, Meta block, two consecutive detail failures, or a failed checkpoint can leave details incomplete without marking an otherwise proven ad list incomplete. Tartol stores only a bounded allowlist of Meta's public detail fields with exact ad-ID correlation and provenance; it does not retain detail request bodies, cookies, tokens, headers, or raw response bodies.

Exact per-ad detail, targeting-country, EU-transparency, media URL, and pagination compatibility is monitored with authorized real Meta probes through supported residential proxy endpoints, including Decodo, across representative advertiser libraries. Authorization confirmation, proxy credentials, and low-level traffic telemetry are platform-wide internal controls and intentionally excluded from the public REST API and MCP actions. The control plane is writable only in production because local and staging previews share the production database. The Cloudflare admin API and Google Cloud collector must use the same canonical proxy-encryption key. Credentialed proxy endpoints use an explicit HTTPS/TLS proxy transport; missing or plaintext HTTP schemes are rejected before credential decryption, certificate verification stays enabled, and there is no HTTP fallback. Tartol Agent can explain the architecture, status, and troubleshooting steps and can direct a super admin to the configuration page. Tartol Agent cannot confirm collection authorization or change proxy credentials.

Understand Daily Activity

Daily Activity counts an ad as launched when Tartol first discovers it after tracking begins. It counts an ad as paused on the day a complete provider refresh no longer returns that ad as active. The pause date is therefore the day Tartol detected the change, which can be later than the moment the advertiser actually paused it.

Tartol retains each detected active-to-paused and paused-to-active transition so later media or analysis updates cannot move historical activity to another day. It also retains the last confirmed-active time as supporting evidence without presenting that time as an exact pause timestamp.

Complete tracked-brand refreshes repeat the same country, status, media, and sort filters with every POST cursor request. Facebook can collapse related ads into fewer collated cards than the displayed result count, so cursor exhaustion—not row-count equality—proves completion. An early lost cursor session can restart once. Persistent failures stop instead of creating a paid retry loop. Any capped, interrupted, or oversized rolling scan leaves missing ads active and never manufactures pause events.

Pause detection happens on the next successful complete refresh. While a library reports more than 2,500 active ads, its rolling refreshes continue finding and updating ads but pause detection is intentionally unavailable. If it later falls to 2,500 or fewer, a complete refresh can safely resume status reconciliation.