Internen Traffic filtern

Interner Traffic (eigene Team-Besuche, Office-IPs, automatisierte Checks) verzerrt dir jede Metrik. Office-Maschinen mit warmem Cache und schnellem Netz sehen super aus; Mobile-Besucher im Tunnel sehen mies aus; und der Durchschnitt von beidem sagt am Ende nichts mehr.

Einen „meine IP ignorieren"-Toggle haben wir mit Absicht nicht; wir speichern keine IPs, siehe Privacy. Was du ausschließen willst, entscheidet, welcher Weg passt.

Bots und Crawler nehmen wir dir schon ab. Auf dieser Seite geht es um deinen eigenen internen Traffic (Office, Team, Monitore). Automatisierter Traffic von Crawlern, Bots, VPNs und Rechenzentrums-Netzen wird automatisch klassifiziert und lässt sich im Dashboard mit einem einzigen Schalter Bots ausblenden verbergen; dafür brauchst du die Optionen unten nicht. Was dabei erkannt wird und wie, steht in der Datenschutz-Übersicht.

Wähle die passende Option

Option 1: Eine separate Application für Non-Production

Saubere Antwort für Staging, Preview, Dev.

1. Leg eine zweite Application in fastmon an, z. B. acme-marketing-staging, und setz ihre environment auf dev, um sie klar von Production zu trennen.
2. Nutze deren source_hash im Staging-Deploy. Eine separate Application hat ihr eigenes Snippet und eigene Hashes; die Domain als weitere Site unter derselben Application hinzuzufügen, würde das Production-Snippet wiederverwenden.
3. Ignorier die Staging-Application in Dashboards oder nutze sie absichtlich; Staging-Metriken sind nützlich, um Regressionen vor Production zu fangen.

Kostet dich nichts: keine Client-Logik, keine Flags, kein Risiko, dass Production-Daten in Staging landen oder umgekehrt.

Option 2: Beacon bei internen Sessions weglassen

Nützlich für Office-Traffic, wenn der Besucher Zugang zum Backend oder Admin-UI hat und du ihn dort als „intern" markieren kannst.

Einfachster Weg: das Beacon-<script> einfach nicht rendern, wenn der Request aus einer internen Session kommt. Serverseitig entscheiden anhand des Signals, das du eh schon hast: Session-Cookie, JWT-Claim, Admin-Login.

{% if not request.session.is_staff %}
  <script src="https://fastmon.site/s/{source_hash}.js" defer></script>
{% endif %}

Reine Client-Variante geht auch: Script-Tag nur einfügen, wenn das Cookie fehlt, das du einmal auf einer /staff-Route setzt:

<script>
  if (!document.cookie.includes('staff=1')) {
    var s = document.createElement('script');
    s.src = 'https://fastmon.site/s/{source_hash}.js';
    s.defer = true;
    document.head.appendChild(s);
  }
</script>

Option 3: Site komplett pausieren

Für Wartungsfenster, eine Investigation oder eine Nicht-Production-Umgebung, die permanent laut ist:

1. Öffne in fastmon die Site und geh auf Einstellungen.
2. Schalte Active ab.

Beacons kommen weiter an, werden aber nicht in Analytics-Tabellen geschrieben. Wieder einschalten, wenn du Daten willst. Historie aus der aktiven Phase bleibt erhalten.

Option 4: Beacon für synthetische Monitore weglassen

Für Pingdom, UptimeRobot, eigene E2E-Suiten etc.: das Script gar nicht erst laden. Die meisten Monitore setzen einen erkennbaren User-Agent; Script-Tag serverseitig weglassen:

{% if request.user_agent.is_synthetic %}
  <!-- Fastmon für synthetische Checks weglassen -->
{% else %}
  <script src="https://fastmon.site/s/{source_hash}.js" defer></script>
{% endif %}

Wenn dein Stack keinen einfachen „ist Bot"-Check hat, steuere das Script-Tag direkt im Template über den UA; gleiches Prinzip.

Filter verifizieren

Site als interner Besucher öffnen. DevTools → Network → c/ filtern. Du solltest keinen Request an https://fastmon.site/c/... sehen. Wenn doch, wird das Script-Tag weiter gerendert; Gate-Bedingung auf dem Server (oder den Cookie-Check im Inline-Snippet) prüfen.

In fastmon nach dem Umschalten: Der Traffic aus dem Land deines Office-Standorts sollte deutlich kleiner werden (das Land ist die einzige Geo-Dimension, die wir speichern). Wenn nicht, fängt der Filter die internen Besuche nicht.

Häufige Stolperfallen

• Nachträglich filtern geht nicht. Wir speichern keine IPs (siehe Privacy). Sobald ein Beacon drin ist, können wir nicht mehr sagen, ob der aus deinem Office kam. Also: an der Quelle filtern.
• Das Gate läuft pro Seite. Auf jeder Seite weglassen, die du ausschließen willst, nicht nur beim ersten Load.
• Country-Filter helfen nicht. Dein Office sitzt im gleichen Land wie die meisten echten Besucher. Was funktioniert: an der Quelle filtern, wo der echte Kontext (Besucher, Cookie, UA) noch da ist.

Verwandt

• Sites: separate Sites für Umgebungen.
• Tracker-Einstellungen: was der Beacon erfasst.
• Privacy: was wir nicht sammeln: warum es keinen serverseitigen IP-Filter gibt.