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, click Retry — that sets the same session up again, you do not need to start a second one. That status only appears after several automatic attempts, which can take a few minutes. The session names the cause in plain words; the technical message sits below it behind Technical details, and that is what we need if you ask us about it (see below).
• If the portal reports that all test proxies are in use, try again in a few minutes.
• The session stops automatically: after 3 hours at the latest — and already after 30 minutes in which no request arrives. Those 30 minutes run from the start of the session and restart with every captured request, so set your test device up promptly. You can stop it earlier at any time.

Address, offering identifier and QR code are blurred in the screenshot — your own session shows your values there.

2. Connect your test device¶

The session leads with the Connect your device card: the QR code for the VPN tunnel, the steps, and the Download .conf button. The tunnel is the route for everything — websites as well as apps, desktop as well as mobile. Below it, collapsed, sits Set your device's DNS instead: the DNS address is the fallback for when the tunnel is not an option.

Why the recommendation: the DNS route is a redirection, and it depends on the device actually asking us for the hostname. Already cached names, open connections and applications with their own resolver bypass it. The tunnel operates below name resolution, does not have that problem, and also captures HTTP/3.

Recommended: VPN tunnel¶

In the session, the QR code is right there in the Connect your device 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.

Fallback: DNS address¶

For when the tunnel is not an option — and not for Android (see above). In the session, expand Set your device's DNS instead: it holds a DNS server address (IPv4, with a copy button) and, under How to set your DNS on each platform, the path for each platform. Set that address 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.

For websites this route only captures if you turn off encrypted DNS (DoH) in the browser — otherwise the browser asks its own resolver, the test proxy never sees the calls, and the page loads normally all the same. The DNS route is reliable for apps, which use the system resolver.

One thing only this route can do: check a measurement hostname before public DNS points at the new measurement infrastructure. That is why it stays.

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 session itself tells you whether it can hear your device: until something arrives it reads Waiting for the first request from your device…, and with the first captured request it switches to Capture confirmed ✓ together with the age of the most recent one. That is the first place to look — it confirms the measurement, whereas the counters in the WireGuard app only confirm the tunnel.

The filter bar has the fields Site, Time (1 h, 6 h, 24 h, 7 d) and Type (IOMB, IOMP, All) — applied with Apply. What is shown are the requests from your own session. 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 — except that it announces it. Roughly five minutes before, the session shows a notice, and it says different things depending on the reason: if the lifetime is running out it tells you to wrap up; if it is the half hour without a request, it tells you that a single call keeps the session alive. Once the deadline has passed it says the session is being stopped now — taking the proxy down takes a few minutes more.

The notice then stays up and says what to revert on the device: switch the tunnel off in tunnel mode, set the DNS server back to automatic in DNS mode. Do not rely on watching it happen, though — the DNS route runs into the half hour easily, and if the DNS address is still set on the device afterwards, no name resolution works there at all. It looks as if the internet is broken, and that is the first thing to check when a test device suddenly cannot reach anything.

Notes¶