Gravity Forms can display aggregate survey results while exporting individual entries through the standard export workflow. Teams searching for an export button on the summary screen can miss field IDs, choice values, score mappings, date filters, conditional fields, partial entries, deleted choices, and spreadsheet encoding that determine whether the CSV can reproduce the report.
Use this for analysts, researchers, nonprofit teams, educators, support teams, and developers who need Gravity Forms survey data in CSV or another reporting system.
Quick answer
Choose Forms, Import/Export, Export Entries, then select the survey form, required fields, date range, and conditional filters. Export the individual entries as CSV. Before analysis, preserve the raw file and create a mapping from form ID, field ID, field label, choice text, stored choice value, score, and question type. Reconcile response counts and exclusions with the survey results screen. Use WP-CLI only when its access, filters, and output are documented.
What to check first
- Record Gravity Forms and Survey Add-On versions, form ID, entry statuses, date zone, field IDs, labels, choices, scores, and conditional logic.
- Define whether the request needs aggregate survey results, individual responses, scores, free text, partial entries, spam, or deleted entries.
- Select explicit export fields and filters, preserve the raw CSV, and record the export UTC time and row count.
- Map field IDs to labels, choice text, stored values, scores, question types, and historical form revisions before renaming columns.
- Reconcile raw entry counts, exclusions, score totals, multi-select expansion, encoding, and missing values with the summary view.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Define the report grain and eligible entry population. | Record Gravity Forms and Survey Add-On versions, form ID, entry statuses, date zone, field IDs, labels, choices, scores, and conditional logic. | Export row count matches the eligible entry population. |
| Export explicit fields and filters from the entry export workflow. | Define whether the request needs aggregate survey results, individual responses, scores, free text, partial entries, spam, or deleted entries. | Field IDs, choice values, labels, scores, and revisions are mapped. |
| Preserve the raw CSV and build a versioned field mapping. | Select explicit export fields and filters, preserve the raw CSV, and record the export UTC time and row count. | Date and conditional filters reproduce the intended subset. |
| Normalize values only after historical choices and scores are understood. | Map field IDs to labels, choice text, stored values, scores, question types, and historical form revisions before renaming columns. | Raw CSV, normalized dataset, and survey summary differences are explained. |
Why this usually happens
- The survey results page is an aggregate report, not the entry export screen.
- Field labels can change while field IDs and historical stored values remain.
- Choice text and score values are not always the same data.
- Spreadsheet software can alter dates, leading zeros, Unicode, and multiline fields.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
form_id,entry_id,field_id,label,stored_value,choice_text,score,status
18,410,3,Service,q3_good,Good,4,active
18,410,4,Recommend,9,9,9,active
18,411,3,Service,q3_okay,Okay,3,active
18,412,3,Service,q3_old,Historical label,2,active
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| All complete entries | No date or conditional filter | Row count matches eligible entries |
| Date range | Boundary entries in site time zone | Documented inclusive result |
| Conditional filter | Choice value, not visual label | Expected subset |
| Revised choice | Old and new stored values | Mapping preserves history |
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Define the report grain and eligible entry population.
- Export explicit fields and filters from the entry export workflow.
- Preserve the raw CSV and build a versioned field mapping.
- Normalize values only after historical choices and scores are understood.
- Reconcile rows and totals against the survey summary and source entries.
Decision rule
Approve the export when every row maps to an eligible entry, every survey field has a versioned ID-to-value mapping, and counts, exclusions, scores, and filters reconcile with the documented report definition.
Production verification checklist
- Export row count matches the eligible entry population.
- Field IDs, choice values, labels, scores, and revisions are mapped.
- Date and conditional filters reproduce the intended subset.
- Raw CSV, normalized dataset, and survey summary differences are explained.
Field notes
- Keep survey respondents anonymous in reusable evidence.
- Open the first export as raw text before using a spreadsheet.
- Document whether partial and spam entries are intentionally excluded.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only confirmation and one narrow synthetic fixture that cannot charge a card, email a real customer, expose personal data, or change inventory. Perform destructive repairs, upgrades, cache changes, and schema work on staging first.
What evidence should the report keep?
Keep exact versions, UTC timestamps, stable synthetic IDs, expected and actual results, the decision owner, rollback point, and final verification. Redact customer data, credentials, tokens, addresses, and private infrastructure details.
When is the task complete?
Complete the task when the primary user path passes, downstream records reconcile, failure branches are understood, monitoring is active, and an established owner page links to the new guide in context.
Mistakes to avoid
- Changing production before recording exact versions, UTC timestamps, stable fixture IDs, current settings, and a reproducible baseline.
- Treating one successful screen as proof that background jobs, APIs, caches, roles, reports, and downstream records agree.
- Deleting logs or identifiers before the failure boundary, business impact, rollback point, and accountable owner are known.
- Testing only an administrator session instead of the devices, roles, networks, data states, and failure paths real users have.
What to tell the client or owner
Give the site owner the affected versions, exact synthetic fixture, UTC timeline, before and after evidence, current cause class, decision, rollback point, unresolved risks, and next review date. State which measurements prove success and which observation window remains open.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, build a reliable Gravity Forms export.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Preserve historical survey scoring meaning
After field mapping is stable, use the Gravity Forms survey historical choice score drift audit to version labels, values, weights, rules, exports, and downstream metrics by effective date.
Helpful references