Symfony Metrics Laravel Package

Product Decisions This Supports

• Analytics strategy: Whether to ship first-party, privacy-preserving metrics and SEO visibility rather than relying entirely on third-party analytics SaaS.
• Roadmap prioritization: v0.6.0 makes SEO crawl verification a supported, in-product capability. If an SEO reporting surface is on the roadmap, this release reduces the build work required to prove site ownership and enable crawling.
• Build vs. buy: The core metrics capability is increasingly commodity; the differentiators are data ownership, self-hosting, low client-side footprint, and compliance friendliness. This release strengthens the “buy/embed, don’t build” case for teams that want SEO insights without adding another vendor.
• Release/adoption decision: v0.6.0 is additive and low-risk. seo_crawl defaults to false, so existing behavior is unchanged. Adopt now if SEO reporting is an active need; otherwise defer until it is.
• Operational readiness: Enabling SEO crawl introduces a public, unauthenticated /.well-known/quietmetrics.json endpoint. Product and platform owners should decide whether exposing this path is acceptable and ensure WAF/CDN/cache rules allow GET/HEAD while respecting Cache-Control: no-store.
• Security/configuration decision: The feature requires secret_key and is intentionally runtime-gated via env because the listener is always registered. This supports environment-specific rollout but requires clear ownership of secret rotation and configuration hygiene.

When to Consider This Package

Consider this package when:

• You need self-hosted, privacy-friendly web/product metrics and want to minimize third-party scripts and data sharing.
• You operate a PHP application and want analytics/SEO visibility integrated close to the application rather than as a separate SaaS dependency.
• You have compliance or data-residency constraints (GDPR/CCPA, internal security review) that make third-party analytics tools costly to approve.
• You specifically want the SEO crawl/site-ownership verification capability added in v0.6.0, and can expose /.well-known/quietmetrics.json.
• You can manage environment-driven configuration and a secret_key, and you have a runbook for rotating it.

Look elsewhere when:

• You need full product analytics such as funnels, cohorts, session replay, experimentation, or warehouse-native analysis.
• You require enterprise support, SLAs, or a fully managed service.
• You need a deeply Laravel-native package with first-class Laravel conventions; confirm the integration path and framework support before committing.
• Your security posture cannot allow a public well-known endpoint, or your WAF/CDN cannot reliably pass GET/HEAD without caching.
• You do not want to own infrastructure, upgrades, secret management, and monitoring.

How to Pitch It (Stakeholders)

For executives: v0.6.0 adds opt-in SEO crawl verification to our privacy-friendly metrics capability. It is off by default, so there is no behavior change unless we enable it. When enabled with a secret key, the application serves a small ownership-proof JSON file at a standard well-known path so the metrics SEO tab can crawl the site and report visibility. This supports a first-party, data-owned analytics approach and reduces dependence on third-party tracking vendors. The upgrade is additive and low-risk, with a dependency bump to quiet-metrics/php-metrics ^0.6.

For engineering: The release adds a SiteVerificationListener on kernel.request at priority 200, main request only. It is always registered because the seo_crawl value comes from the environment at runtime. When seo_crawl=true and secret_key is set, it serves GET/HEAD /.well-known/quietmetrics.json as application/json with Cache-Control: no-store; otherwise requests pass through untouched. Confirm the well-known path is allowed through the firewall/WAF/CDN, ensure secret_key is configured and rotated, and verify no router/session assumptions are broken by the early listener priority.

Decision requested: Approve the minor upgrade, confirm whether SEO reporting is a near-term priority, and assign an owner for secret_key management and monitoring of the well-known endpoint if the feature is enabled.