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.

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.