- Optimizely Forms collects the data subject's user name (of the currently authenticated user on the website) and the browser IP address to perform those features if you configure Optimizely Forms to:
- not Allow anonymous submissions
- not Allow multiple submissions from the same IP/cookie
You should inform the data subject about this, using the Form description or Forms confirmation message, before the data subject submits the form.
- Any page that uses Optimizely Forms to request input of PII data should be using HTTPS protocol, TLS 1.2 or later.
- If you use the Hidden visitor profiling feature, Optimizely Forms collects data from data subject's browser request. You should inform the data subject about it.
- You should inform the data subject about how the user's data is used and to what purpose. Put that information in the form description, or use a Rich text element, to inform and summarize at the last step, before the data subject submits the form.
See also Collect data.
If you are using Optimizely Forms, you are probably collecting PII, and as with all other PII data, you should ensure that sensitive data is appropriately protected, and that consent is captured along with the PII. See also Ask for consent.
When creating forms, you need to take the following issues into consideration:
- If you use features described in the Collecting Data section, Optimizely Forms might collect data. You can turn this off in each form setting.
- Get consent (if necessary) and consider the following:
- State clearly the purpose of the data collection in the forms description.
- Use a check box element to ask for consent.
- Build a customized form field in Optimizely for a consent check box to allow the editors easily manage the consent type and message.
- Form elements that collect PII data should not be mandatory. Make the consent optional for different types of PII data independently (that is, visitors should be able to consent to the collection of their email address but not their phone number, for example).
- If you need to change a form currently in use, make a copy and leave the historical form intact, to ensure submissions and consent reflect the current form. Alternatively, add a “Hidden predefined value”, which includes the full consent text, so the consent is stored with the submission.
- Feature to check the “DNT” header on the request will be implemented soon in built-in FormElement. The DNT functionality will be overridable, so that partners can build their own “Do not track” implementation.
- Introduce an appropriate retention policy, such as deleting partially completed form submissions within 30 days and completed form submissions when they are no longer useful.
Optimizely Forms stores its data submissions in the DDS, as does the Optimizely Content Management System (CMS) database. The data that is stored might be PII data, and is thus consider as PII data.
- Historically, data is stored for a long time, but an Information Lifecycle Management (ILM) - Data retentions) feature is planned.
- Partially filled-in submissions are deleted regularly.
On-premises installations require encryption of your database instance TDE and encryption at rest.
You might not use Optimizely as the final destination for form submissions. You can use forms as the ingress point, to redirect the submissions to other endpoints (CRM, Marketing Automation, and so on) by using Webhook or the Marketing Automation Integration connector. In this case, submissions (or PII) are stored at another place.
See also Store data.
- The data submissions should be accessed and used carefully. See Restricting access to data.
- Developers can process form submissions through the Forms Service API. Developers should consider excluding PII data before processing, and do not show DataSubmission in other places.
- Editors can view form submissions through the edit view.
- Editors can export submission data to a file in JSON, XML, or CSV format. The exported data should be considered PII data, and therefore not be stored in some other unsafe store. Restrict the permissions to this feature carefully.
- Optimizely Forms submission storage should not be considered as a long term or permanent storage.
- Having it as a temporary buffer is an acceptable solution.
- You should configure the ILM feature (Data Retention) when it is available to clear the storage periodically.
- No editing feature is planned to modify submitted value.
See also Data guidelines.
Data collected by forms are usually point-in-time changes such as signing up, requesting information, or reporting address changes. Such data should be deleted after the visitor was responded to, or after the data was recorded at the destination. If you do need to find form submissions from a specific individual, recent versions of Optimizely Forms (Forms 4.14.0 and later) have a built-in search capability, which can be used to export submissions. See also Fetch and update data.
- Data Submissions cannot be accessed via the Forms Service API by default. To let developers read the data, it must be explicitly configured (for each form).
- After configuration, developers should be able to fetch most types of data using the API.
- You should use the upcoming ILM feature to delete data after 30 days.
- Partners are able to delete most types of data.
- Developers can use the Optimizely Forms API.
- Editors can use the View form submissions feature in the CMS edit view.
- A more advanced search user interface will be provided to help editors locate and delete data.
- There is no backup of the form submissions. When you delete it, it is gone from the CMS database. However, there might be backups of the database.
- If data submissions are sent to other third-party products (like Marketing Automation Integration systems, or other systems via Webhook), Optimizely Forms cannot control the data.
See also Delete data.
Updated 4 months ago