Countly API Changes

We tried to make the API compatible the same way, so there are not many changes except for one specific endpoint for accessing data at the collection level.

If you are using DBViewer API and access data per drill collection in an API call similar to this:
https://yourdomain/o/db?api_key=API_KEY&dbs=countly_drill&collection=drill_eventsf51b86c60e3985f4332ffe708677b82896718ffe&query={}

Then, you will need to change the collection name to drill_events and put the event you query as part of the query

https://yourdomain/o/db?api_key=API_KEY&dbs=countly_drill&collection=drill_events&query={"e":"Login"}

Countly DB Viewer changes

When accessing data using the DB Viewer section of the dashboard, previously, there were separate collections per app per event, and you could view data for each event separately with the app's read permission.

Then, in the new version, all those events for all apps will be under a single collection, drill_events, and you will only see the events for the apps you have read access to.

If you want to see a specific app and specific event, you would need to add a filter to do that, for example for the app with id 60a94dce686d3eea363ac325 and event Login, the query would look like this:

{"a":"60a94dce686d3eea363ac325", "e":"Login"}

Using BI Tools with Countly

It will be easier to use BI tools with Countly because you do not have to think about specific collection names, which are derived from the app ID and event key. Instead, you can query only one single countly_drill.drill_events collection and construct any queries that you need.

You can utilize the "a" property of the documents to query for specific app data and the "e" property of the documents to query for a specific event key.

MongoDB query for the app with id 60a94dce686d3eea363ac325 and event Login would look like this:

{"a":"60a94dce686d3eea363ac325", "e":"Login"}

Accessing MongoDB Data Directly

If you connect directly to MongoDB to query or export data, check if the collections you are using start with drill_eventsSOMEHASH. If yes, you would need to modify the collection name to drill_events and apply the app and event you want to query as a MongoDB query.

MongoDB query for the app with id 60a94dce686d3eea363ac325 and event Login would look like this:

{"a":"60a94dce686d3eea363ac325", "e":"Login"}

Listening to drill data using Kafka

In the past, if you were consuming drill-related data using Kafka, you were likely listening to the entire MongoDB database and then filtering the data from collections that started with the prefix drill_events. This broad approach could lead to unnecessary overhead, especially if you're only interested in specific data from a particular collection.

Now, with more granular control, you can switch to listening to a single collection, specifically the drill_events collection (not collections that merely start with that prefix). This refinement allows for more focused and efficient data processing, as you're no longer dealing with multiple collections, but instead, you're subscribing to just the one that holds all the relevant event data.

For example, with MongoDB’s Change Streams and Kafka integration, you can consume data from the drill_events collection using Kafka, like this:

{
    "pipeline": [
        { "$match": { "operationType": "insert" } }
    ]
}

If you're interested in listening for specific apps and/or events within that collection, you can apply an aggregation pipeline directly within the Kafka consumer. For instance, if you only want to capture data from app with ID "5ab0c3ef92938d0e61cf77f4" and event "Login", you can use properties afor App ID and e for event key, so your filter would look like this:

{
  "pipeline": [
    { "$match": { 
        "operationType": "insert", 
        "fullDocument.a": "5ab0c3ef92938d0e61cf77f4",
        "fullDocument.e": "Login"
     } }
  ]
}

This ensures that only events matching your criteria are streamed to Kafka, reducing unnecessary traffic and focusing on the exact data you're interested in. Moreover, this targeted approach helps improve system efficiency and allows you to fine-tune your data processing.

Using Countly-provided Scripts to Export Data

All internal scripts have been modified to use the new data scheme. So if you are using any of the Countly provided scripts, you can find the modified version in the respective directory in the new release here.