Telemetry: Custom CSS is over-tracked (per-keystroke, ~78% of all events) — replace with bucketed depth + error signal

Aperta
  • Qualcosa non va?
#2,867 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
70/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
javascript
Ambito
frontend, observability

Direzione di ricerca

Inizia da src/css/editor.js, concentrandoti sull’handler onChange e sul flusso debounced checkInput, poi leggi INSIGHTS.md §1 e i telemetry PRs referenziati come precedente. Il lavoro è completo quando viene rimosso l’evento per ogni pressione di tasto e vengono emessi bucket keyed di size e validation per ogni blocco, preservando il consent gate esistente.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

Otter over-tracks Custom CSS: the editor fires a telemetry event on every keystroke, and the event carries no payload. In the latest 3-month usage window this single event was 5,194 of 6,658 total events (78%) — it dominates the dataset, drowns out every high-intent feature (Conditions, Forms, AI) in the raw feed, and yet tells us nothing actionable.

This proposes replacing the per-keystroke counter with two low-cardinality, non-PII signal events emitted on the validation settle that already runs — cutting ~78% of event volume and finally answering whether Custom CSS is a one-off tweak or a power-user layer, and how often it's invalid.

Current behavior

src/css/editor.js (~L108–116):

const onChange = () => {
    window?.oTrk?.add({ feature: 'custom-css', featureComponent: 'used' });
    clearTimeout( inputTimeout );
    inputTimeout = setTimeout( () => { checkInput( editorRef.current ); }, 500 );
};
editorRef.current.on( 'change', onChange );
  • oTrk.add(...) fires on every CodeMirror change (i.e. per keystroke), outside the existing 500ms debounce.
  • The payload is just { feature: 'custom-css', featureComponent: 'used' } — no featureValue, so it answers only "someone typed in the box," at extreme frequency.

Why this is a problem

  • Noise + skew: 78% of all tracked events. The usage dashboard needs a log-scale toggle purely to see past it; week-over-week movement is mostly CSS keystroke jitter, not product signal.
  • Pipeline waste: dozens of batched events per editing session where one would suffice.
  • Zero insight: the event can't distinguish a 2-line tweak from a 200-line stylesheet, can't say which block, and can't say whether the CSS is valid.

Proposed change

  1. Delete the per-keystroke oTrk.add({ feature: 'custom-css', featureComponent: 'used' }) at L109.

  2. Inside the already-debounced checkInput() (runs 500ms after typing settles; it already computes editorErrors and has the CSS value via editor.getValue()), emit two keyed oTrk.set events per block (set, keyed by block clientId, so it dedups to the latest state per block per settle rather than accumulating):

    // size: coarse bucket by CSS volume (e.g. rule/declaration or non-empty-line count)
window?.oTrk?.set( `custom-css-size-${clientId}`, {
    feature: 'custom-css', featureComponent: 'size-bucket', featureValue: sizeBucket   // '0' | '1-3' | '4-10' | '10+'
});

// validity: coarse bucket of lint errors (always emit, including '0')
window?.oTrk?.set( `custom-css-errors-${clientId}`, {
    feature: 'custom-css', featureComponent: 'validation', featureValue: errorBucket   // '0' | '1-2' | '3-5' | '6+'
});

    (Exact bucket edges are open to tuning; the point is bounded, low-cardinality enums.)

Compliance

  • Non-PII, no payload: never send the CSS text itself or any lint-error message — only the bucketed counts above. featureValue stays a closed enum string.
  • No consent change: reuses the existing window.oTrk (tiTrk.with('otter')) accumulator and the existing otter_blocks_logger_flag consent gate. No { consent: true } bypass.

Expected impact

  • ~78% reduction in tracked event volume; the dashboard's other features become legible without log-scale gymnastics.
  • New, decision-relevant signal: is Custom CSS a quick one-off tweak (→ candidate for a native control) or a power-user escape hatch (→ protect it), plus a CSS error rate that feeds the broader durability/quality picture.

References

  • Usage analysis: INSIGHTS.md §1 (the 78% / 5,194-event figure) and the telemetry-expansion roadmap item "A1 — Custom CSS depth + error bucket."
  • Pattern precedent: PR #2862 (block add/remove tracking) and the sibling telemetry PRs #2864 / #2865 / #2866.
Lingua principale
PHP
Stelle
200
Fork
37
Merge medio
1g 13h
PR unite (30g)
30

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Codeinwp/otter-blocks

Tutte le issue di Codeinwp/otter-blocks

Issue simili

Altre issue su PHP

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.