dabrock.ai · Service · AI Performance Marketing

How we measure — every enquiry can be proven

You pay per qualified enquiry. That only works if both sides see the same number. These two diagrams show the whole path: from the ad to the enquiry on your invoice.

Offer as PDFBack to home
01 · Multi-tenant platform

Each tenant has its own landing pages, its own SEO and GEO pages, its own ad accounts and its own board; the data stays separate. A parent tenant — a group or an agency — sees its tenants individually and combined. A new tenant is a configuration, not a rebuild: which is why a page goes live in days, not weeks.

flowchart TB
  subgraph account["Parent tenant — e.g. a group or an agency"]
    direction LR
    M1["Tenant A<br/>own landing pages<br/>own SEO and GEO pages<br/>own ad accounts · own board"]
    M2["Tenant B"]
    MN["Tenant n<br/>a new tenant =<br/>configuration, not a rebuild"]
  end

  subgraph plattform["Shared platform"]
    DB[("Data storage<br/>separate per tenant")]
    EIN["Enquiry intake<br/>form · phone · e-mail"]
    TAG["Server-side tag management"]
    BOARD["Management board<br/>per tenant and across all"]
    BEW["Approval and scoring per enquiry"]
    WACHT["Watchdogs<br/>click counting · cost import<br/>checks · morning digest"]
    EIN --> DB
    BOARD --> DB
    BEW --> DB
    WACHT --> DB
  end

  ADS["Ad accounts per tenant<br/>Google Ads · Microsoft Ads"]
  ORG["Search engines and AI systems<br/>no budget per enquiry"]

  M1 --> EIN
  M2 --> EIN
  MN --> EIN
  M1 --> TAG
  M2 --> TAG
  MN --> TAG
  TAG --> ADS
  WACHT --> ADS
  BEW -->|"value per enquiry"| ADS
  BOARD -->|"report per tenant"| account
  ORG -->|"organic enquiries"| EIN
  M1 -.->|"content · structured data<br/>profile for AI answers"| ORG
On narrow screens, swipe sideways.
02 · From the ad to the invoiced enquiry

Two directions you must not confuse: measurement counts what happens in the browser. The return channel reports later what an enquiry was actually worth — so bidding learns from real customers, not from clicks.

flowchart LR
  subgraph browser["In the browser"]
    KLICK["Ad click<br/>with click ID"]
    SUCHE["Search result or AI answer<br/>without click ID"]
    SEITE["Landing page"]
    SEO["SEO and GEO page"]
    CONS["Consent<br/>Consent Mode"]
  end

  subgraph erfassung["Captured on our side"]
    FORM["Form · phone · e-mail"]
    DB[("Enquiries with source<br/>separated by channel")]
    LOG["Server log<br/>counts even without consent"]
    PREIS["Cost per enquiry<br/>paid and organic apart"]
  end

  subgraph platt["Ad platforms"]
    G["Google Ads"]
    M["Microsoft Ads"]
  end

  subgraph rueck["Return channel"]
    BEW["Scoring per enquiry<br/>value from real business"]
    UP["Value reported back<br/>within the deadline"]
  end

  KLICK --> SEITE
  SUCHE --> SEO
  SEITE --> CONS
  SEO --> CONS
  SEITE --> FORM
  SEO --> FORM
  FORM --> DB
  LOG --> DB
  DB --> PREIS
  CONS -->|"measurement"| G
  CONS -->|"measurement"| M
  DB --> BEW
  BEW --> UP
  UP -->|"bidding learns from real customers"| G
  UP --> M
On narrow screens, swipe sideways.

Source per enquiry

The click ID is part of the page request. We read it from the server log — even when a visitor allows no cookies.

One number for everything

Board, nightly report, weekly report and invoice all read the same view. There is no second counting rule that could disagree.

Checked before sending

Every night, checks run against expected values. If a number deviates, an error message goes out before any report is sent.

Approval, not assertion

You decide per enquiry: accepted or rejected. Only what both sides agreed on gets invoiced.

Cost per channel, not on average

Every channel carries its own cost per enquiry — paid ads kept apart from search and AI answers. Only then can you see where budget belongs and what building organic pages actually saves.

The diagrams deliberately omit server, account and client names. Within a project you receive the same view for your own environment, with all names and identifiers.