Links

Alerting

mediarithmics modules can trigger alerts to grab the attention of users/integrators on specific points to improve or fix.
Alerts are displayed in the UI, but can also be accessed by API if you want to automate actions or grab them in your own reports.

Alert types

Here are the different alert types that exist today
Type
Trigger
Displayed
SEGMENT_COMPUTATION_ERROR
An error during the calculation of a segment
On the segments page. For more information, see Using the Segments page
SEGMENT_VOLUME_DROP
A segment volume drops by more than a configured threshold (in percentage).
In the segment computation process, after it has been computed, we check
  • If volumes have dropped by more than XX%
  • If none of the segment labels are in the blocklist when in blocklist mode
  • If any of the segment labels are in the allowlist when in allowlist mode
On the segments page. For more information, see Using the Segments page

Alert properties

Alerts have several properties associated with them:
  • id: The unique identifier of the alert.
  • datamart_id: The identifier of the datamart associated with the alert.
  • organisation_id: The identifier of the organisation associated with the alert.
  • community_id: The identifier of the community associated with the alert.
  • type: The type of the alert (e.g., SEGMENT_COMPUTATION_ERROR, SEGMENT_VOLUME_DROP).
  • created_ts: The timestamp indicating when the alert was created.
  • archived: A flag indicating whether the alert is closed/archived (true) or open (false).
  • archived_ts: The timestamp indicating when the alert was closed/archived.
  • archived_by: The identifier of the user that closed/archived the alert.
  • expiration: The expiration timestamp for the alert.
  • count: The number of times the alert has been triggered.
  • count_last_ts: The timestamp of the most recent trigger of the alert.

Polymorphism

The alerting system supports polymorphism to accommodate specific fields for different alert types.

Alert target

Alert target depends on the alert type. It could be a segment, but also an import, a feed, or any other type of object.
Alerts will always have a property object representing the target. You don't have to do multiple queries to have important info.
Alert target
Property name
Sample value
Segment
segment
{
'segment_id': 'xxx',
'segment_name': 'The segment name',
'segment_type': 'USER_QUERY',
'user_points_count': 71989,
'feeds_count': 0
}
Others will come

SEGMENT_VOLUME_DROP particularities

Those alerts have a drop_rate field representing the total drop (in percentage) of the segment volume since the alert was first triggered

Open/Close

To provide a familiar terminology to users, alerts can be opened or closed. However, in the system, the open/closed state is represented by the archived field. Opening an alert sets the archived field to false, while closing an alert sets it to true. The closed state implies that the alert is no longer active or visible to users.

Preventing duplicates

To avoid having multiple instances of the same alert, the system employs a prevention mechanism. Each alert has count and count_last_ts properties. When triggering a new alert, we check if there is already an active alert for the same target. If such an alert exists, the system increments the count property and updates the count_last_ts to reflect the latest trigger. This prevents the proliferation of identical alerts and ensures that only one alert remains active with an incremented counter.
For example, if a segment has a query error and the issue persists without resolution, the system will increment the count property of the existing alert rather than creating multiple duplicate alerts.
The count_last_ts property stores the timestamp of the most recent trigger, while the created_ts property stores the timestamp of the initial trigger.

Expiration

To manage the storage of alerts and ensure their relevance, the system implements an expiration mechanism. Alerts have an expiration duration associated with them. It is set to the created_ts + 1 month. You can't modify this behavior.
A cleaning job runs regularly to identify and delete all expired alerts from the database. This prevents the accumulation of unnecessary historical data.

API

The API allows users and integrators to interact with alerts through the following functionalities:API
get
https://api.mediarithmics.com
/v1/alerts
Retrieve a list of alerts based on specific criteria
You have to fill in either the organisation_id, datamart_id or community_id parameters.
Archived alerts are not returned by default. You need to ask them through the archived parameter.
Parameters
Query
organisation_id
Int
ID of the organisation in which to find alerts
datamart_id
Int
ID of the datamart in which to find alerts
community_id
Int
ID of the community in which to find alerts
type
AlertType
Such as SEGMENT_COMPUTATION_ERROR. See Alert types.
archived
Boolean
true to return archived alerts.
Responses
200: OK
List of alerts
401: Unauthorized
You don't have access to the organisation, datamart or community
put
https://api.mediarithmics.com
/v1/alerts/:alertId
Change the status of an alert from open to closed or vice versa
Parameters
Path
alertId
Int
ID of the alert to edit
Query
archive
boolean
true to close an alert, false to open it.
Responses
200: OK
OK. Returns the new alert object.
400: Bad Request
Missing parameter: archive
401: Unauthorized
You can't open/close this alert
delete
https://api.mediarithmics.com
/v1/alerts/:alertId
Parameters
Path
alertId
Int
ID of the alert to delete
Responses
200: OK
401: Unauthorized
No other operations or modifications are permitted through the API.
Users and integrators are restricted from editing any field other than the archived flag for an alert.