Managing Custom Alert Rules

This guide is going to help you to customize how the AdSecure's crawler is going to determine if a violation should be considered or not as an alert.

If you're not familiar with GraphQL, please have a look at its dedicated section in this documentation.

The AdSecure's crawler is configured to inform you about the violations found during an analysis by comparing its results with the international standards. That said, you might want to customize the way these violations are reported.

At AdSecure we call these custom settings Alert Rules where an alert is a violation that you consider as critical.

Let's consider that for example, a Landing Page Error is critical on your network and should be considered as an alert. To do so, we need to create a new alert rule where this specific detection is going to be alerted.

In the same way as for the creation of a new analysis, creating an alert rule is associated with a mutation in GraphQL.

By default, all the violations are not considered as alerts. The entire list of Violation is available and can be retrieved by running the following query:

query {
  violations(first: 50) {
    nodes {
     login
    }
  }
}

Prerequisites

Before starting this guide, please be sure that you're ready to use our service by following the steps illustrated in the Quickstart section.

Simple case

For creating a new alert rule we need to send a payload that contains the following fields:

• The name that's going to help us to easily remember the role of this alert rule. This value is also going to be used to generate the alert rule's login.
• An array of violations' login that we want to alert - as values of the violations field.

Query

mutation {
  createAlertRule(input: {
    name: "Landing page error",
    violations: [
      "landing-page-error"
    ]
  }) {
    login
    name
    violations {
      login
      name
    }
  }
}

Response

{
  "data": {
    "createAlertRule": {
      "login": "landing_page_error",
      "name": "landing page error",
      "violations": [
        {
          "login": "landing-page-error",
          "name": "Landing Page Error"
        }
      ]
    }
  }
}

We can now use this alert rule when we create a new analysis. To do so, we need to set the alert rule's login as additional parameter to the example illustated in the First Analysis's guide and we ask the API to return us an additional field alertViolations:

Query

mutation {
  createAnalysis(input: {
    content: "https://examples.adsecure.com/404",
    alertRule: "landing_page_error",
  }) {
    id
    alertViolations
  }
}

Response

{
  "data": {
    "createAnalysis": {
      "id": "YW5hbHlzaXN8YThiYzk0M2ItNTY3ZS00NzA5LWIwOWItMTI1YmMzNGMxMjUwfDIwMTgtMDktMDI=",
      "alertViolations": ["landing-page-error"]
    }
  }
}

That's it!

The analysis is going to be processed as usual, but if your content is not accessible at that time it won't be considered as an alert and you won't be notified about it!

If we then fetch the analysis you can see that event if a Landing Page Error was detected by our crawler and reported as a violation, it will be considered as an alert:

Query

query getAnalysis {
  analysis(id: "YW5hbHlzaXN8YThiYzk0M2ItNTY3ZS00NzA5LWIwOWItMTI1YmMzNGMxMjUwfDIwMTgtMDktMDI=") {
    id
    content
    status
    alert
    violation
    violations
    alertViolations
  }
}

Response

{
  "data": {
    "analysis": {
      "id": "YW5hbHlzaXN8YThiYzk0M2ItNTY3ZS00NzA5LWIwOWItMTI1YmMzNGMxMjUwfDIwMTgtMDktMDI=",
      "content": "https://examples.adsecure.com/404",
      "status": "DONE",
      "alert": true,
      "violation": true,
      "violations": ["landing-page-error"],
      "alertViolations": ["landing-page-error"]
    }
  }
}