Introduction
GFDB (https://gf-db.github.io/gfdb/index.html) is a database collecting data from GFL’s crafting system. Here you can view statistics on specific Dolls/Equipment/Fairies as well as the recipes used to craft them.
Voodoos, especially cheaper recipes or recipes including or excluding certain equipment used to be actually more efficient. However, due to updates with client version 3.01, using recipes that are not Mica Recommended Recipes is no longer recommended.
Locating Recipes and Data
When opening the website, you are presented with different subsections on the various types of craftables in GFL. Sorting can be done through clicking on the column description (for example mean%). Clicking again will change the sorting from high → low or the other way around. Right-clicking on a column will remove the sorting for that column. Remember that the order you sort in will change how things are displayed (for example, rarity first into mean% will give you 5☆s at the top with the highest rates above the lower rates.
To find data on a specific Doll/Equipment/Fairy and all the recipes that can drop it/them:
- Pick the type you are looking for.
- Pick the actual thing you are looking for.
- Sort by mean%.
- Check the data.
To check any specific recipe recipe:
- Select the recipe.
- Sort rarity → mean%.
How to Read Data
There are a few notes we must cover on how statistics and GFDB works:
Stdev and actual craft total
Stdev (standard deviation) shows how reliable a recipe is, lower is better. Recipes with low total crafts do not have reliable rates.
Stdev measures how much reasonable variation there might be between the observed crafting rate and the "true", underlying crafting rate. This exists b/c we only have a finite number of pulls to observe the rates from, which is prone to variation.
Consider the following example: if you flip a (possibly weighted) coin twice, and see heads twice in a row, it would be unreasonable to conclude that the rate of seeing heads is 100%. However, it is more likely that the coin is biased towards heads than it is towards tails. Furthermore, the more times you flip the coin, the more certain you would be that the observed rate is close to the actual rate. For this reason, the more times you try the experiment, the lower the stdev of the estimated probability.
Going back to GFDB, it is for the exact same reason that recipes w/ more total crafts have lower stdevs. We have more records of these recipes, so we also have more confidence in the observed rate. It is also for this reason that some so-called "voodoo" recipes w/ limited numbers of pulls may seem to have much higher drop rates of particular dolls at first: this is very similar to observing two heads in a row after flipping a coin twice.
Therefore, it is best to avoid recipes with low total crafts and/or high stdevs, as the nominal rates are very unreliable.
CR and Epochs
CR (Capture Rate) shows how many of the crafts in the currently selected Epoch were actually collected in the database as a percentage.
Example of how the collected data actually works. Note how 2☆s stop being shown past the 11th entry and so on. As such, data past the 11th entry needs to be treated carefully.
Capture rate is the term used for the fraction of total crafts captured in the database. For technical reasons discussed here, not all of the userbase's crafts are published by MICA, especially when many crafts happen at once, most notably during rateups. For the same technical reasons as above, the crafts that are not published are overwhelmingly from the lower rarity pools, meaning that, when the capture rate is low, the rate that GFDB shows for 4☆s and 5☆s is skewed significantly higher than the actual rate is. In particular, you can estimate the true crafting rate by multiplying the reported crafting rate with the capture rate, as explained in the image below.
An Epoch is a period of data collection with no changes to the pool or rates or other things that might affect the rate. For example any rate-up would be a separate Epoch, as the rates are different from non-rate-up. If you do not separate out rate-ups or similar changes to the crafting pools, the data becomes useless. Epochs are denoted as a number with a decimal, the full number is just which Epoch this is while the decimal denotes that it is separated by other Epochs in between.
For example, a new Doll batch adds new units to the pool which requires a new Epoch. This Epoch then gets interrupted by Costume Gacha rate-ups, as well as other interruptions whenever there is a General Rate-up or similar. As the actual pool doesn’t change outside new Dolls being added, non-rate-ups since the new Doll batch is all one Epoch but it is split into parts 1, 2, 3 etc, but all the data will be the same for the entire Epoch.
Technical Details
An rather thorough explanation can be seen in these two images:
-
Part 1
-
Part 2
Blog posts by the GFDB owner on how GFDB works and such:
http://www.tlmc.eu/search/label/GF
Most notably these two blog posts and their comments:
https://www.tlmc.eu/2018/11/girls-frontline-statistics.html
https://www.tlmc.eu/2019/04/gf-statistics-parts.html
Taiwan has their own GFDB here (note that this is far less user friendly than EN GFDB and is also missing Capture Rate, making the data potentially very misleading):
https://gf-data-tools.github.io/gfdb-tw
