Grouping of similar push notifications

We've setup what we call a "Transactional" push notification. These notifications are triggered by external events and targeted to very few (usually a single) user. Think of the delivery notes pushed to the Amazon app as an example.

This push notifications are triggered by external events and sent to Countly via the API interface. We can have a look at them in the API tab of the Messaging section, but they are listed one by one. It would be great to give the push notification an internal "group" property, that is transmitted when creating the push notification via API, so that those push notifications are grouped together for analysis (opening rate, etc.).

The group property would only be internal, but it would also be great to have the "Push notifications for various channels" (https://support.count.ly/hc/en-us/community/posts/900001468946-Push-Notifications-for-various-channels-?input_string=Grouping%20of%20similar%20push%20notifications) in addition to that-.

1

Comments

6 comments
  • Hello Michael,

    I have made a formal feature request for this and will keep you dated. Thanks!

    -Andreas

    1
    Comment actions Permalink
  • Hi Michael,

    What is the difference between automated and transactional notifications? You said "Think of the delivery notes pushed to the Amazon app as an example" for transactional notifications, which is a notification type I'm currently using with "automated".

    Thank you in advance,

    Metin Ozsoy 

    0
    Comment actions Permalink
  • Hi Metin,

    Andreas showed us this article:

    https://support.count.ly/hc/en-us/articles/360037270012-Push-Notifications#transactional-notifications-beta 

    I think that is exactly what we're looking for (apart from "Beta" and "not for production use"), but we haven't actually tried it, yet.

    The "transaction" in my use case is triggered from a different system. In case of the delivery note it is triggered by our ERP system. I'm not sure how you'd use the automated notifications for this (unless the ERP system writes an "event" or similar into Countly).

    Best regards,
    Michael

    0
    Comment actions Permalink
  • Hi Michael,

    Thank you for your answer. I've also read the link you've provided. It'll be very useful feature for us. I'll contact with my development team, we may voluntarily test it!

    Thank you,

    0
    Comment actions Permalink
  • I gave it a go today and there are a few issues with this approach at the moment:

    1. The API documentation needs an update... The endpoint /i/pushes/push gives very little information on how the data needs to be structured (does the messagePerLocale need to be in the data section? same question for the userConditions? date is mandatory? etc.)
    After a lot of trial and error I found out, that this structure works for us. An example request in the documentation would help a lot:

    {
    "_id": "605857d1b222c133a06687e7",
    "messagePerLocale": {
    "default":"Override for the message",
    "default|t":"Override for the message title"
    },
    "userConditions": {
    ...
    }
    }

     

    2. When the message is created with the /i/pushes/create endpoint, the message is displayed in the "Scheduled" state in Countly (as per documentation). When sending a push notification via the /i/pushes/push endpoint the message is sent and the notifications are grouped as expected. But because the message status is still "Scheduled" you won't see the percentage bar of actioned notifications. Manually setting the status to "Sent" in the database, will reject any future messages.

     

    0
    Comment actions Permalink
  • Turns out: With Countly version 20.11.1.5 you have a separate tab "Transactional Messages" which properly summarises the messages and also gives you statistics. So scratch bullet point 2 from the list. From my point of view the FR can be closed.

    0
    Comment actions Permalink

Please sign in to leave a comment.