Websites herunterladen, die snigel AdEngine nutzen

Über snigel AdEngine

Header Bidding muss im Browser des Besuchers stattfinden, in den Augenblicken, bevor die Seite überhaupt etwas von einem Ad-Server anfordert. Eine Monetarisierungsvereinbarung, die sonst eine private Geschäftsangelegenheit zwischen einem Publisher und seinen Demand-Partnern wäre, landet deshalb als Skript im Markup, für jeden lesbar, der hinschaut. snigel AdEngine ist eines dieser Skripte.

Dort hält das Skript eine Auktion ab. Der Wrapper fragt mehrere Käufer gleichzeitig nach einem Preis für denselben Werbeplatz und reicht dann das Gewinnergebot weiter, damit das Inventar nicht stillschweigend an den Ad-Server verkauft wird, der zufällig als Erster gefragt wurde. Um diesen Kern herum liegen die operativen Details, die darüber entscheiden, ob sich die Vereinbarung tatsächlich rechnet: wann Werbeplätze geladen werden, wie mit Einheiten unterhalb des sichtbaren Bereichs umzugehen ist und wie viele Bieter man abfragen kann, bevor die Latenz mehr kostet, als der zusätzliche Wettbewerb einbringt.

Für Forscher ist vor allem interessant, wer dafür bezahlt. Unser Eintrag nennt Publisher Collective als Anbieter hinter dem Produkt, und der Wrapper wird als Managed Service verkauft, was bedeutet, dass sich der Publisher entschieden hat, die Feinabstimmung auszulagern, statt dafür Personal einzustellen. Eine Website mit diesem Skript ist daher werbefinanziert, groß genug, dass der Unterschied zwischen einem guten und einem schlechten Auktions-Setup Geld wert ist, und klein oder ausgelastet genug, dass eine eigene Stelle dafür nicht sinnvoll war. Das ist ein recht enges kommerzielles Profil, und es ist von außen sichtbar, ohne den Publisher irgendetwas zu fragen.

Die Technologie selbst ist schnell beschrieben, lässt sich aber eindeutig erkennen. In JavaScript geschrieben und seit 2015 am Markt, gehört sie zu der Generation von Wrappern, die entstand, nachdem Publisher erkannt hatten, dass ihnen mit nur einer Ad-Server-Beziehung Umsatz entging. Stand Oktober 2026 erfassen wir den Wrapper auf 37 Websites, durchweg unter der Lizenz Proprietary und ohne selbst gehostete Variante, die die Zählung verfälschen könnte.

Die Erkennung hat hier echte Grenzen, und sie wirken nur in eine Richtung. Wrapper-Code wird mal über einen Tag-Manager eingefügt, mal unter einem publisherspezifischen Dateinamen gebündelt, und auf vielen Websites lädt er überhaupt erst, wenn eine Consent-Abfrage beantwortet ist, was ein Crawler nicht tut. Jeder dieser Fälle führt dazu, dass wir eine Website übersehen, und nicht zu einem falschen Treffer. Der tatsächliche Bestand ist also größer als die Zahl, die wir zuordnen können.

Für einen Demand-Partner, einen konkurrierenden Wrapper-Anbieter oder einen Analysten, der die unabhängige Publishing-Landschaft kartiert, ist die Liste selbst das, worauf es ankommt. Zu wissen, dass eine einzelne Website den Wrapper nutzt, ist eine Randnotiz. Wer den gesamten Bestand kennt, also was diese Websites veröffentlichen, in welchen Ländern ihre Domains liegen und was sie sonst noch laden, kann ein Marktsegment dimensionieren, eine Akquise-Liste planen oder verfolgen, ob Publisher von einem Export zum nächsten den Anbieter wechseln.