It is possible to populate deltaDNA with data from your game even if it has been running for a long time. 

Please contact our support team to make arrangements first, as there are often special considerations for each game. If you just start pumping old data in to deltaDNA you will find that events older than a certain date will be rejected. We will need to relax the acceptable date range boundaries on your game whilst you backfill your data.

Some things to consider:

Data Format

The preferred method for sending legacy data is through the deltaDNA REST API as this ensures the data is subject to the same validation and processing conditions as live events. A translator / processor may be needed to convert your legacy data to deltaDNA events, this is something that you can do in house or have deltaDNA undertake for you. 

Event Detail

Before sending all your historic data you will want to think about how you are going to use it. You may find that some events in your older data are less valuable than when they were current. For example, knowing about player sessions and revenue from two years ago may be important but some more finely grained events are less likely to be as valuable. Besides, you are unlikely to hold your entire data history in your "HOT Data" window to run analytics queries against. Your game and players evolve and you are more likely to be interested in trends rather then fine detail in older data.

It is also possible to send player summary events to give the platform information about players without backfilling their entire history. For example you could send an event for each player containing playerStartDate, daysPlayed, totalSessions, userXP, userLevel, totalRevenueSpent etc.. 


Historic data should be sent in chronological order as the deltaDNA platform calculates player metrics for each player as data arrives. If data arrives out of sequence it can invalidate make many of these metrics. 


The following checklist can be used to make sure all aspects of backfilling historic data are covered.

  1. Find out what data you are looking to access in the DeltaDNA platform.

  2. Define a set of events that represent the data you want to bring across.

    1. This could be the start dates of players, their total spender status, their daily activity and the levels played.

    2. Keep in mind that raw event data is only stored within the retention window, for backfilled data it is not unusual the raw events will be deleted the next day, the user and daily aggregates will persist however.

    3. Once the event definition is clear and described in for example a spreadsheet deltaDNA can quickly do a sanity check on the setup.

  3. Next set up the events and metrics in the deltaDNA platform.

  4. Map the existing data onto the new events and and store them.

  5. Use the stored events as input to QA the events.

    1. Keep in mind that events older than 31 days will fail the event window check in the interactive event validator but we can temporarily set a custom value for the event window.

  6. Make sure the data acceptance window is adjusted by deltaDNA to match the oldest events, let us know.

  7. Send in some events into the dev for another QA pass, no events should be marked as invalid.

  8. Then send in all events (in chronological order per user) to the live environment.

    1. Sending the events can be done in bulk but single requests should be no larger than 5 mb and they should be sent in in sequence.