myAudit — inspect measurement requests in real time¶

myAudit shows the measurement requests from your own test device in real time: which requests arrive, with which page code, and which category that code is mapped to. It lets you verify an integration before go-live without working through log files.

You can test websites and native or hybrid apps (iOS, Android).

New: both measurement methods in one test. The consent-free census measurement (IOMb) and the pseudonymous measurement (IOMp) run in the same session and the same list — one page view tells you whether both are working, and the Type filter switches between them. Until now myAudit covered only the census measurement; the pseudonymous one needed a second tool.

How the marking works¶

What is marked is not the individual request but the route: you send your test device's measurement calls through a test proxy that you start yourself in the portal. Our measurement systems recognise it by its IP address and attribute every call arriving that way to your session — identically for both measurement methods.

Nothing is decrypted on the way: on the DNS route, TLS connections are passed through by hostname (SNI passthrough, the certificate comes from the target system); in the tunnel, packets are forwarded unchanged.

Check first¶

• The measurement has to be live. The test proxy only knows measurement domains whose certificate has already been issued and is active. A measurement domain you have just created, whose CNAME does not resolve yet, is invisible to myAudit — see setting up the measurement domain.
• Know your offering identifier (st), otherwise you will not recognise your own rows. What the parameters mean: parameter reference.
• IOMp requests exist only if the pseudonymous measurement is built in.
• A device whose network settings you are allowed to change, on a network that lets the necessary traffic out: outbound UDP 51820 for the tunnel, outbound port 53 for the DNS route. On managed company devices you often are not allowed to; a forced corporate resolver, or a pinned "Private DNS" on Android, prevents capture without showing an error.

1. Start a session¶

In the portal, go to MyAudit and click Start MyAudit test. Provisioning takes 1–2 minutes, after which the session shows you how to connect your test device.

• One session per user at a time. If one is still running, stop it first.
• If the session shows status Failed, start it again. That status only appears after several automatic attempts, which can take a few minutes. If it persists, send us the error text shown (see below).
• The session stops automatically after 3 hours; you can stop it earlier at any time.

2. Connect your test device¶

The session shows two cards side by side for this. The tunnel is the recommended route — it captures reliably and needs no setting on the device. The DNS address is the shortcut for a quick test in a desktop browser.

Why the recommendation: the DNS route only sees calls for which the device resolves the hostname anew. Already cached names, open connections and apps with their own resolver bypass it. On Android there is a second problem — the manual DNS setting, along with the static IP configuration, is lost on a reboot, an airplane-mode toggle or a "forget network", so capture ends mid-test without an error message. The tunnel has neither problem, and it also captures HTTP/3.

Recommended: VPN tunnel¶

In the session, the QR code is right there in the Option 2 — VPN tunnel card, with a Download .conf button below it for desktop machines. There is nothing to request.

Only traffic to our measurement endpoints is routed through the tunnel; everything else on the device goes out directly.

1. Install the free WireGuard app (Android, iOS, Windows, macOS).
2. In WireGuard, tap + or Add tunnel and choose Scan from QR code.
3. Scan the QR code from the session, give the tunnel a name (anything, e.g. myAudit-Test) and create it. On a desktop, import the file from Download .conf instead.
4. Switch the tunnel on and check the connection: tap the tunnel — the counters under Transfer increase and there is a successful latest handshake. If the handshake never happens, your network is probably blocking outbound UDP port 51820 — test from a different network, for example over the device's mobile data.

The screenshots show Android; on iOS the steps are named the same. After a device reboot the tunnel is usually off — check the handshake again before concluding that the measurement is broken.

Shortcut: DNS address¶

For a quick test in a desktop browser. The Option 1 card shows a DNS server address (IPv4, with a copy button). Set it as the DNS server on your test device and replace any existing entries — a second DNS server of your own next to it means part of the calls bypass the proxy and the list stays empty although everything looks correctly set up.

Leave the second DNS field empty, turn encrypted DNS off for the duration of the test (DoH / "Secure DNS" in Chrome and Firefox, iCloud Private Relay), and restart the browser before you open the test page — otherwise it uses a cached name and never asks the proxy.

3. Inspect the requests¶

Open the page you want to test, or use your app. The requests usually appear in the list within seconds.

The filter bar has four fields — Site, Time (1 h, 6 h, 24 h, 7 d), Type (IOMB, IOMP, All) and Session (default: your own session only) — applied with Apply. In the table, your offering identifier (st) is in the Site column, the page code (cp) in Code, and the mapping derived from it in Category.

What to check:

• Does one census request arrive per page view?
• Does Code show your page code — and not Leercode_nichtzuordnungsfaehig? That value means no code was passed: the request is measured, but nothing can be attributed.
• Does the category in Category match what the code is supposed to mean? A "—" means this code is not mapped yet.
• Is the domain in Domain the expected one? This is where calls arriving under a foreign host show up, for example via an AMP cache or a proxy.
• Do IOMp requests appear after consent? They normally do only then; seeing only IOMB before that is correct.

The user agent is deliberately not shown in the IOMb detail view.

Requests are kept for 7 days and then deleted automatically. That applies to the myAudit view, not to your measurement data.

4. Finish the test¶

The device first, then the session:

1. Switch the tunnel off, or set the device's DNS server back to automatic.
2. Stop the session in the portal.

The other way round leaves your device without working name resolution — the proxy's address is released when the session ends and can later be assigned to someone else.

The same applies when the session ends by itself: it expires after 3 hours, without a notification. If the DNS address is still set on the device after that, no name resolution works there at all — it looks as if the internet is broken. That is the first thing to check when a test device suddenly cannot reach anything.

Notes¶