Privacy and data handling

Your downloadable scores, result JSON, audit report, item diagnostics and method comparison are created from the analysis response and remain only where you choose to save them. The scores, the method comparison and the result JSON hold one row per respondent, named by the identifier column you chose. The result JSON also carries the run’s provenance with the three fingerprints described below; the scores file and the report carry the fingerprint of the data only.

Statistical analyses

A statistical analysis on the What can I analyse? page sends its results back to you, in the response to your request, and to nobody else. They can include counts, summaries such as means, medians and the smallest and largest value, estimates with their confidence intervals, test statistics and p-values, and frequency tables, cross-tabulations and histograms. Each result also carries a provenance record of the run: when it ran, the engine and rule versions, the names of the analysed columns, the numbers of rows, the method and its decision, and the fingerprints described below. In the results, category labels appear only for the columns you analyse, and never for a column that looks like an identifier or free text. While you set an analysis up, a column you open shows its categories too, as described under Response categories during setup below. None of it is kept after the request completes.

Small numbers are held back by provisional display rules. Histogram bars are joined until each holds a minimum number of observations. The smallest and largest values are shown only from a minimum number of valid observations. Small cells of frequency tables and cross-tabulations are hidden, together with the other counts, totals and percentages in the table that would reveal them. The limits are part of the analysis engine’s published thresholds. These rules are not an anonymity guarantee: an exact smallest or largest value can still single out an unusual person, and group sizes are always shown. Statistics of the whole table also stay in the result: the test and, for a two-by-two table, the difference in percentages, the odds ratio and phi. With the table’s totals they can give back the hidden counts of a small table, and other figures in a result can narrow a hidden count down or give it back exactly: the number of answers, the mean and the standard deviation of a question with three answer options determine its three counts. Estimates are not held back either: a model with a categorical predictor gives the mean of each category, however few rows it holds.

Fingerprints

Results carry keyed fingerprints: digests (HMAC-SHA256) made with a key that only the server holds. A statistical analysis carries one of the request and, when it was not held back and rests on at least ten rows, one of the data as analysed. A score result carries one of the data, one of the analysis and one of the set of respondent identifiers, all three in its result JSON; its scores file and report give the one of the data. Someone who holds the record but not the key cannot test guesses against them. Anyone who can run analyses on the same METER service can, though: the service gives the same data the same fingerprint, so by sending a file and comparing fingerprints they can check whether it is the data you analysed. When no key is configured no fingerprint is issued, and the result says that it is unavailable.

Response categories during setup

During setup, METER displays the response categories detected in the item columns you select so you can confirm their coding. It does not return row-level data or retain uploaded values.

The first inspection of a file reports only column names, data types, row and column counts, missing-value counts and distinct-value counts, and suggestions built from them, such as which columns may form a scale. The first step of a statistical analysis also reports data-health findings, as counts and shares of rows (for example how many rows repeat an earlier one), never a value from a cell. Under the same floor as the tables, a finding does not say how many rows hold one category or value of a column when that number, or the number of all the other rows, is below five; that includes the cells holding a placeholder such as NA, a word such as “none”, text among numbers, a limit such as “<5” or an answer outside the range you confirmed. Three counts are given whatever their size: the rows with an answer in each column (and so its empty cells, among them those holding such a placeholder or word; in a column holding one value, the rows at that value), the rows that share an identifier with another row, and the values far from the rest or outside the usual range. When you score a questionnaire, category labels and candidate missing codes are shown only for the item columns you explicitly select, only in the response to that request, under fixed limits (at most twelve categories per item, no row-level values, no identifiers, nothing from unselected columns), and are never written to logs.

A statistical analysis shows the same for any column you open while setting it up, whether or not it is an item: its category labels or answer codes under the same limits, the value labels stored in the file, and any value that looks like a missing-value code (for example 999 in a column of ages), with the share of answers it would remove. That share is not a frequency table, but with the column’s number of answers it gives the number of rows holding the code, also when that is below five; scoring a questionnaire gives the same share for its candidate codes. They are shown only in the response to that request and are never written to logs. Nothing is shown for a column you do not open, and no categories are listed for a column that looks like an identifier, free text or dates.

Feedback

If you send feedback, METER stores the category, the text you submit, the page you sent it from, the time and any email address you choose to provide. When e-mail notification is set up, the same entry is also e-mailed to the METER team. This information is used to improve the research preview and, if requested, to contact you. No questionnaire data or analysis results are attached to feedback.

Accounts

Your data pass through METER. They don’t live in METER.

METER is in an invited beta. Creating an account stores your email address, a hashed password, the time the account was made, the invitation code used and whether the account is active. No name and no organisation are attached to it, and no uploaded data and no analysis output ever are. Passwords are never stored: what is kept is a scrypt hash with a salt unique to your account, from which the password cannot be recovered. If you ask for a password reset, a hash of the single-use reset code is stored with the times it was issued, expires and was used. That record is kept until the account is deleted, even after the code is used or has expired; a code that was never used is replaced when a new one is issued. Redeeming a code signs out every other session on the account.

You can also sign in with Google or GitHub. With Google, METER asks only for your email address and receives that address, whether Google has verified it, and Google’s identifier for your account. With GitHub, METER’s server reads your GitHub profile and the list of email addresses on your account to find GitHub’s identifier for you and your primary verified address; it uses nothing else from them and does not store or log them. In either case METER stores only the email address and the provider’s identifier with your account, so it can recognise you next time. METER never stores the provider’s access token, and no password exists for such an account. Whether an address may sign in this way is decided by a list the METER team maintains, of addresses or whole domains, each with a short note of the team’s and the time it was added; nothing is created for an address that is not on it.

An account is required to analyse your own data. The demo, the comparison and the evidence pages stay open to everyone without one. An account identifies you; it does not change what METER analyses. What you upload is still discarded after the analysis, and so is every score, estimate and report METER produced from it: they exist only where you choose to save them.

Two further things are planned for accounts, both kept only at your request. Neither is available yet, so today an account holds only what is listed above. Instrument definitions you save: the names of the item columns, the response coding you confirmed, reverse scoring, the factor structure, missing-value rules, the name of the respondent-ID column, the coding minimum and number of categories, the data-provenance label, and a name and version for the instrument. A definition describes how a measure is scored; it contains no response from anyone, and it is the same specification you can download as a file. A provenance record for each analysis you run while signed in: the time, the saved instrument and revision it used (or the definition’s fingerprint if you did not save it), the METER and model versions and checkpoint digest, the capability-contract versions, a cryptographic fingerprint of the analysed data, the inferences you requested, the decision METER reached and the codes of its warnings, and the runtime. A provenance record lets you show which version produced a result and confirm later that a file is the same data you analysed. It holds nothing derived from your data beyond the fingerprint: not a value, not a column name, not even the number of respondents or items. The fingerprint is the keyed digest described under Fingerprints above, with the same limits, and it changes if the data or the definition change.

METER does not retain uploaded datasets, respondent-level data, latent scores, item estimates or generated analysis outputs, with or without an account. Once these features exist, you will be able to rename or delete a saved instrument and delete any provenance record at any time from the workspace. Ask for your account to be removed and the account record, its saved definitions and its provenance records are deleted and overwritten in the service’s database. Feedback you chose to send with an email address attached is a separate record, and we will remove that too if you ask.

The hosted service keeps the account database and the feedback records on a storage volume of its hosting provider, which takes a daily snapshot of that volume and by default keeps each snapshot for five days. A record that is deleted stays in the snapshots taken before its deletion until they expire. How often snapshots are taken and how long they are kept are settings of the host, not of METER’s application.

Two records are kept apart from the account. If your address is on the list of addresses allowed to sign in with Google or GitHub, it stays there, with the team’s note, until the METER team removes it: deleting the account does not remove it from that list, and while it is listed, signing in again creates a new account. If your account was made with an invitation code, the code stays recorded as used, with the time, the account’s internal identifier and any note the team made of whom it was for: deleting the account does not remove that record.

Explanations

A result page can offer a plain-English overview of your run and a box for asking questions about it. When that feature is enabled, METER sends a short aggregate summary of the run to a language-model provider: once when METER’s decision is shown, to write the overview, and again each time you ask a question, together with the question you typed. The conversation is held in your browser tab for as long as the analysis is open. METER’s server keeps none of your questions and none of the answers. It keeps the overview in memory, so that the same summary is not sent twice, until the service restarts. The provider handles what it receives under its own data terms.

This feature is offered with scores from Analyse your data and with the demo. Results of a statistical analysis are never sent to it.

The summary is built by the server from the result. It holds counts, the capability decision for each requested inference, agreement and reliability statistics, data-quality warnings, the runtime, and the scale or factor labels you declared yourself. It never holds respondent identifiers, scores, responses, item column names or any value from your file, and nothing respondent-level can be placed in it: the server accepts only a fixed set of summary fields. The model cannot see your data and cannot change METER’s result; an answer that would go beyond what METER reported is withheld and the page says so. When no provider is configured the feature is absent and nothing is sent.

Product analytics

METER records day-level counts for a small, fixed set of product events, such as a completed demo or a refused analysis. These events cannot contain filenames, column names, questionnaire responses or score values: the event vocabulary is a strict whitelist enforced by the server, so there is no field those values could travel in. METER does not use cookies, device identifiers or session tracking for these events.

Logs

METER’s own logs record that something failed: the kind of error and the place in the code. They never record the content of a request: no file, no value, no column name, no result and no question. Where logs are kept, and for how long, is set by the hosting provider.

Hosting and network infrastructure

The network and hosting services used to deliver the application may process standard connection metadata such as IP addresses, request paths and timestamps under their own policies. METER request paths do not contain questionnaire responses or analysis values. How long those services keep that metadata is set by them, not by METER.

During the research-preview phase the deployment environment may change, and the provider terminating TLS can technically observe upload payloads rather than metadata alone. For restricted or controlled datasets, do not use this hosted preview.

How the guarantee is implemented

This section describes the deployment as it runs today. It depends on framework versions, parser libraries and hosting, and it may change. The guarantee above does not change with it, and it is the only data-handling claim other pages repeat.

• Uploads above roughly 1 MB, in any format. The web framework buffers the request body to a private temporary file before application code runs, and removes it when the request ends. Smaller uploads are held in memory.
• SPSS and Stata files. Those parsers require a file path rather than a byte stream, so the bytes are written to a temporary file of their own and deleted as soon as parsing finishes, including when parsing fails.
• CSV, TSV, Excel and Parquet below the buffering threshold. Parsed directly from memory.
• Upload-processing paths. Uploaded questionnaire data and analysis outputs are not written to durable application storage. Temporary upload-processing files are deleted as part of request cleanup. Feedback you choose to send, and day-level usage counts, are retained as described above.
• Statistical analyses. Each step sends the file again, so nothing from it is held between requests. The display limits are configuration of the analysis engine and are published with its thresholds.
• What the service holds in memory. Sign-in sessions (your account’s identifier and email address): each is checked against the account when it is used, so a session of an account that was deleted or disabled ends at its next request, and until then, until a check after it expires drops it, or until the service restarts, its record stays in memory (a session that made no request while its account was disabled is valid again if the account is enabled again); one-time sign-in state; to limit abuse, each account and network address that has made a request, with the times of its requests in the minute before its latest one, kept until the service restarts or the list grows so long that entries idle for a minute are dropped; and recent explanation overviews, keyed by a digest of the summary rather than the summary itself. All of it is lost when the service restarts.
• Logs. The hosted service writes no per-request access lines. Failures are logged by error type and code location only. Credential-like values in a web address are redacted from any request line that is written.

Operational limits such as the maximum accepted file size are served by the application and displayed on the upload page, so the figure shown is the figure in force.

Terms of research use

• METER Research is a research preview provided for research use without warranty.
• Research use only: METER has not been validated for individual diagnosis, screening, treatment, eligibility or other consequential decisions.
• Analyses are governed by a versioned capability contract. If a request falls outside the currently supported region, METER may refuse it or limit the outputs returned.
• Relative uncertainty is a within-analysis ordering diagnostic. It is not a confidence interval or credible interval.
• Scores are estimated conditional on the respondents present in a run. Adding or removing respondents changes every score, so scores from separate runs are not comparable.
• You are responsible for ensuring that you have permission to process any data you upload.
• Upload de-identified data only. Files must not contain names, e-mail addresses, free-text comments or other direct identifiers; you are responsible for removing them before upload.
• Terms governing controlled or restricted datasets take precedence over this research preview.
• Please do not use the shared service for load testing, scraping or automated bulk scoring.

Preprint

At present, this web preview is the only access route METER offers to external researchers. The Python package, source code and model weights are not publicly distributed.

Who is responsible

This service is operated by METER Research, which is accountable for the processing described on this page and is the point of contact for any question about it: hello@meterresearch.ai.

If your study needs a data-processing agreement, an institutional security review or a written assurance before you may send data to an external service, write to that address before you upload anything. This is a research preview, and no such agreement is in place by default.

Contact

The feedback form on any results page reaches METER Research directly and is the route for bug reports and feature requests. Data-handling concerns are read with priority, and reach the same place as the address above. Nothing about your dataset accompanies a feedback message unless you type it.