Hi Antonio, My suggestion is to conduct a survey instead of implementing telemetry in JMeter directly.
We could potentially reconsider telemetry after reviewing the survey results, especially if we include a question asking users whether they would find such a feature useful or not. Regarding GDPR, I agree that this is indeed a critical issue that we must monitor closely. Regards, Milamber Le mar. 2 juin 2026 à 15:33, Antonio Gomes Rodrigues <[email protected]> a écrit : > Hi > Why launching a survey if telemetry is off by default? > > However, a quick warning regarding GDPR (Europe) > > Le lun. 1 juin 2026 à 20:21, Milamber <[email protected]> a écrit : > > > Hi Vladimir, > > > > This proposal is indeed very interesting and aligns well with the models > > used by the project Airflow with ASF Matomo. > > > > However, I would like to raise a point of caution: some large > > organizations have strict security policies that prohibit the > > transmission of any telemetry data, even on an opt-in basis. > > > > As an initial step, perhaps we could consider launching a survey (using > > a tool like Google Forms) to gather feedback on JMeter usage, desired > > features, and potentially obsolete elements. > > > > Additionally, we could include questions within that survey specifically > > about this opt-in telemetry proposal to gauge whether users find it > > useful, neutral, or if they are fundamentally against it. > > > > Regards, > > Milamber > > > > > > On 28/05/2026 13:27, Vladimir Sitnikov wrote: > > > Hi all, > > > > > > I would like to gauge the community's appetite for adding **opt-in, > > > anonymous usage telemetry** to JMeter. Nothing is built yet, and > nothing > > > would be built without rough consensus here first and sign-off from the > > ASF > > > Privacy Committee. This thread is to test the idea and shape the data > we > > > would collect. > > > > > > ## Why > > > > > > We make maintenance decisions with little evidence about how JMeter is > > > actually used. Telemetry would let us: > > > > > > - see which samplers, controllers, and other elements people use, so we > > can > > > prioritise effort and retire dead features with data rather than > > guesswork; > > > - learn which Java and OS versions are still in the field, so we can > set > > > minimum-version policy responsibly; > > > - measure how widely each UI locale is used, so translation effort goes > > > where it helps; > > > - understand how often tests run from the GUI versus the CLI, and at > what > > > scale. > > > > > > ## Principles > > > > > > The proposal is privacy-first by design: > > > > > > - **Opt-in, off by default.** Telemetry starts only after the user > gives > > > explicit consent. We also honour the `DO_NOT_TRACK` environment > variable > > > and a JMeter property to disable it. > > > - **Headless and CI stay silent.** Non-GUI runs cannot prompt for > > consent, > > > so telemetry is off there unless a property explicitly enables it. > > > - **No content, ever.** We never send property values, element or > > test-plan > > > names, file paths, hostnames, IP addresses, target URLs, or any free > > text. > > > - **Built-in identifiers only.** Third-party and custom classes, > > functions, > > > and property keys are mapped to `other` or dropped, so no proprietary > > > package names leak. > > > - **ASF infrastructure.** Data would go to the Foundation's > > GDPR-compliant > > > Matomo instance, with IP anonymisation, not to any third party we run. > > > - **Transparent and auditable.** The payload schema is versioned and > > > documented, and the user can log the exact payload before it is sent. > > > > > > ## What we would collect > > > > > > | Field | Type | Example | Why it is not personal data | > > > |---|---|---|---| > > > | `schema_version` | string | `1` | Constant, set by us. | > > > | `jmeter_version` | string | `5.6.3` | Public release identifier. | > > > | `run_mode` | enum | `gui`, `cli` | Coarse mode flag. | > > > | `os_family` | enum | `linux`, `windows`, `macos` | Family only; no > > build > > > number. | > > > | `java_runtime` | string | `Temurin 17` | Vendor and major version > > only. | > > > | `ui_locale` | string | `ru`, `de` | Language tag; no free text. | > > > | `testplan_size_bucket` | enum | `10-100` | Bucketed element count. | > > > | `thread_count_bucket` | enum | `100-1000` | Bucketed scale of the > > test. | > > > | `distributed` | bool | `false` | Whether remote testing is used. | > > > | `builtin_element_counts` | map | `{HTTPSamplerProxy: 12}` | Counts > per > > > built-in class only. | > > > | `builtin_function_counts` | map | `{__counter: 3}` | Built-in > functions > > > only. | > > > | `modified_property_keys` | set | `[HTTPSampler.method]` | Keys of > > changed > > > built-in properties only. Values are never sent; unknown keys are > > dropped. | > > > | `run_count` | int | `4` | Test runs in the session. | > > > > > > ## What we would never collect > > > > > > Property values, element and test-plan names, file paths, hostnames, IP > > > addresses, target URLs, credentials, custom or third-party class names, > > > custom property keys, and any free text. The block list is enforced by > an > > > allowlist of built-in identifiers, not by a denylist. > > > > > > ## Open questions for the community > > > > > > 1. Is opt-in telemetry something the project wants at all? > > > 2. Does the schema above cover what would actually help us, and is > > anything > > > in it more than we need? > > > 3. How should we count distinct installs for questions such as locale > > > adoption? A pseudonymous identifier is still personal data under GDPR, > so > > > the options range from no stable identifier and approximate counts to a > > > rotating, salted per-day identifier. Input from anyone with GDPR > > experience > > > is welcome. > > > 4. Where should the consent prompt live, and how do we make opting out > > > obvious? > > > > > > If there is interest, the next steps are to refine the schema here, > then > > > take the mechanism and the GDPR specifics to [email protected] for > > review, > > > and finally to VOTE if the change is significant. > > > > > > Looking forward to your thoughts. > > > > > > Thanks, > > > Vladimir > > > > > > > >
