Screenshot of Flo's website
Flo: Research Findings
Flo, headquartered in London, UK, is one of the most popular period-tracking apps on the market with over 380 million downloads.
Long Read
Post date
6th May 2025
Go back to the full report page
Flo, headquartered in London, UK, is one of the most popular period-tracking apps on the market with over 380 million downloads. The app was previously accused of sharing data with Facebook, such as informing Facebook whenever a Flo user was on their period or if they intended to get pregnant. In 2021, the U.S. Federal Trade Commission (FTC) reached a settlement with Flo to undergo an audit of their privacy policy and to obtain user permissions before sharing personal health data.
Flo also launched in 2022 an open-source 'Anonymous Mode' version of the app that allows users to use the app without having to create an account, and the company clarified in a public statement that Anonymous Mode ensures that the app won't be able to identify specific users if asked to do so by law enforcement.
For the purposes of our research, we tested Flo's default mode instead of Anonymous Mode; the app has clarified in its Privacy Policy that regardless of the mode selected, all user data remains safe and secure.
Flo had one of the lengthiest set-up processes, which presented the user with a questionnaire to personalise their profile before accessing their cycle dashboard. Before delving into the questionnaire, we note that upon first launching the app, we were presented with the below consent agreements (Figure 1.1). We were able to proceed with ticking off just the first two boxes. It’s worth noting that Flo took a positive opt-in approach to the consent form, rather than the default pre-ticking of boxes in the opt-out format. That is, the user can affirmatively choose what to consent to, rather than deselecting to indicate consent.
Figure 1.1. In-app screenshot of Flo's privacy agreements for the user. Note the Privacy Policy is presented here at the very start of launching the app and before the questionnaire.
We then proceeded to the onboarding questionnaire, in which the user was asked a variety of questions about their cycle and what they are looking for in the app. The questionnaire allowed us the option to 'Skip' most questions (e.g., cycle duration, last period, height and weight), which we skipped to pursue a data minimalist approach (provide as little personal data as possible to use the app). We were not allowed to skip the question for our year of birth. In their response to our findings, Flo clarified that the purpose of this information is to verify the user’s age (only users 16 or older may use the app).
All our responses to the questionnaire were recorded in the web traffic and sent to the app's application programming interface (API). We noticed this occurred for several of the apps below, as an API facilitates the connection between a computer program (the app) and a computer (the system running the app). In effect, an API is an intermediary that communicates the rules, protocols, and tools that app developers use to interact with external services and databases, or their own libraries for the functionality of the app. In the web traffic, we saw that our required answer for birth year and why we were using the app was sent to the API:
Figure 1.2. See the 'birthdate' field.
Note we were only asked for our birth year, not the month and day, hence the automatic population of 01/01. The 'Path' column in the left-hand side shows all the URL paths the information on the right-hand side is being requested by and sent to, and we see 'birth_date' is being sent to 'api.owhealth', which is Flo's developer's (OW Health) API.
Figure 1.3. See the 'choice' field, populated with 'track_cycle', which we selected among other options like tracking pregnancy.
After completing the onboarding questionnaire, we were able to proceed on the app without having to create an account with our name or email.
Throughout our use of the app, we could see all our cycle inputs also being sent across the web traffic to Flo's API. For instance, we could see our symptoms being requested by the API:
Figure 1.4. See 'symptom_category' and 'symptom_subcategory'
We then noticed that all these logs of our input data (e.g., 'Sad', 'Panic' under 'symptom_subcategory') were being sent over the Cloudflare server (Figure 1.5), a cloud-based content delivery network (CDN) used by many websites and services across various industries. CDNs are increasingly deployed as websites and apps grow their capacity and userbase, and cloud-based servers are highly scalable to accommodate for this growing infrastructure. Flo did disclose by name their use of Cloudflare in their Privacy Policy and labels Cloudflare as a data processor.
As the CDN, Cloudflare facilitates as a ‘man-in-the-middle’ all the communications of the Flo app to its API, such as forwarding the user’s cycle inputs to the API and servicing the app’s chatbot. Technically, Cloudflare operates as a blind forwarder (i.e., a proxy), and Cloudflare confirmed in their response to our report that it is not technically possible for them to turn over any content transiting across their network, nor does it access the data customers choose to send, which is protected under TLS encryption for all data in transit between an end user and any Cloudflare data center. Flo echoed in their response to us that Cloudflare does not access content traveling over its network, and its security-by-design structure ‘significantly limits any potential for unauthorized or excessive access to personal data’.
It’s also worth noting that Cloudflare said they deploy their ‘Privacy Gateway’ for Flo’s Anonymous Mode (which we didn’t test). ‘Privacy Gateway’ encrypts HTTP requests and responses between a client and application server. In practice, this means that request data for Anonymous Mode users is encrypted by Cloudflare between the user and Flo, which prevents Flo from seeing the IP addresses of those users and Cloudflare from seeing the contents of that request data.
Figure 1.5. See server: 'cloudflare' in the Response, with the data in Figure 1.4 being sent in the Request
We similarly saw our period date updates, and our predictions sent over the Cloudflare server to the API:
Figure 1.6. See the requested input data (e.g., 'period_start_date')
Figure 1.7. The Response for the above data Request being received over the Cloudflare server.
Figure 1.8. Symptom Predictions generated and being processed over the Cloudflare server.
We also saw that the algorithm calculated our age based on our birth year entry and sent this to the API (Figure 1.9) over the Cloudflare server (Figure 1.10):
Figure 1.9. See 'age' field. Recall we only provided the birth year, so the age itself was calculated by Flo.
Figure 1.10. The above data Request is processed here over the Cloudflare server.
From here, we sought to try out Flo's chatbot tool, which primarily served as a Q&A screening tool for different health concerns (e.g., acne). These were all controlled multiple-choice chats (the user could only select from provided multiple choice options). We note that this chatbot was also hosted over the Cloudflare network, and each chat session was logged under a unique chat ID:
Figure 1.11. See the chatbot's outputs above, linked to the unique 'id' assigned for this chat.
All our responses in the chat were recorded in the web traffic request, perhaps for the API to provide a response call to the logged user selection. For instance, we can see the API logged our answer of 'mental_conditions_no_answer' over the Cloudflare server:
Figure 1.12. In response to the chatbot's question of what mental health conditions we have, we responded 'I don't want to answer' which the chatbot set as the variable 'mental_conditions_no_answer'
Figure 1.13. We can see the above answer of 'mental_conditions_no_answer' passed to this response here over the Cloudflare server, which returns the chatbot's output of 'Good to know'
We also noticed throughout the web traffic some instances of third-party URL paths from AppsFlyer, which is a San Francisco-based marketing analytics platform that allows developers to measure the performance of their app and/or analyse their marketing activity. In its response to our research, AppsFlyer clarified that it ‘operates strictly as a data processor on behalf of its customers,’ and that ‘all personal data collected by customers through the AppsFlyer SDK is controlled and owned by the customer’. AppsFlyer also stated that any form of data collection on its part occurs under ‘instruction’ by the customer (developer) themselves. That is, any configurations through AppsFlyer’s SDK for data collection as seen below is configured by the customer.
Figure 1.14. AppsFlyer's software development kit (SDK) requesting language, OS, timestamp and device type information.
We note that Flo disclosed to users in both its in-app consent agreement (Figure 1.1) and its Privacy Policy that it integrates third party AppsFlyer. In their response to our research, Flo further clarified that they utilize two different AppsFlyer products, and the AppsFlyer request seen in Figure 1.14 is related to a different purpose than stated in the consent form in Figure 1.1, which concerned marketing attributions. In the above scenario in Figure 1.14, Flo uses ‘third party AppsFlyer to help us identify you as an existing user when you use the App’. (Note that this is disclosed by Flo in their Privacy Policy in a diagram representing their use of AppsFlyer). In scenarios we’ve identified when our technical information was sent to AppsFlyer, this was done ‘for the purposes of determining if the user has already completed the Flo website onboarding journey prior to downloading the Flo App’, and this processing activity is not connected to the marketing purposes in the consent form. Flo clarified that by not consenting to the marketing purposes of AppsFlyer as in Figure 1.1, our device data would not be shared with AppsFlyer for these marketing purposes.
It’s worth noting here that Flo had one of the more robust Privacy Policies that disclosed the use of third parties by name, such as AppsFlyer, as well as disclosing their use of cloud-based services like Cloudflare.
Read more
- Our Research Methodology
- Research findings from the apps
- Analysis: What does this all mean?
- Conclusion and Recommendations
What can I do?
If you want to make sure we can keep doing work like this you can donate now to make sure PI can keep holding governments and companies to account.
Related learning resources