Custom Alerts on Business Metrics: Orders, Conversion, Site Errors

Imagine: overnight, checkout conversion drops by 40%, and technical monitoring is silent — CPU normal, latency normal. Only in the morning does the CEO see the numbers in Google Analytics and lose revenue. Custom alerting rules on business metrics solve this: you learn about a drop in orders or a rise in payment errors within 5 minutes. We have set up such alerts for dozens of e-commerce, SaaS, and content projects. The approach is simple: instrument code with Prometheus metrics, set thresholds considering seasonality, and configure routing to Slack or PagerDuty. The result — reaction time to business-critical problems is reduced from hours to minutes. According to research, an hour of checkout downtime costs a large e-commerce an average of 500,000 rubles. In this article, we'll cover which metrics to monitor, how to implement alerts on Prometheus and CloudWatch, and how to avoid drowning in false positives.

Which business metrics to monitor?

Metrics depend on the product type. We identify three main categories.

E-commerce

• Number of completed orders per hour (sharp drop) — critical for revenue
• Conversion from cart to payment — if it falls below baseline by X%, it's a signal to check the payment gateway
• Revenue per rolling hour — helps quickly detect anomalies
• Number of payment errors — important for the technical team

SaaS

• New user registrations (zero in the last N hours) — signal of a sign-up process failure
• Active users online — unexpected drop may indicate an API issue
• API requests from key clients — anomalous growth or drop

Content projects

• Page views — sharp decrease = SEO or CDN issue
• Bounce rate — sharp increase may indicate slow loading
• Forms submitted — zero in N hours indicates a form bug

How we implement alerts on business metrics

We use two main approaches: Prometheus (for self-hosted) and CloudWatch (for AWS). The choice depends on your infrastructure. From experience, Prometheus offers more flexibility in customization, while CloudWatch integrates better with Lambda and API Gateway.

Implementation via Prometheus

Instrument code with Prometheus client:

from prometheus_client import Counter, Histogram

orders_completed = Counter(
    'orders_completed_total',
    'Total completed orders',
    ['payment_method', 'product_category']
)

order_value = Histogram(
    'order_value_rub',
    'Order value in rubles',
    buckets=[100, 500, 1000, 2500, 5000, 10000, 25000, 50000]
)

payment_errors = Counter(
    'payment_errors_total',
    'Payment processing errors',
    ['error_code', 'payment_provider']
)

Alerting rules for business metrics:

groups:
  - name: business_alerts
    rules:
      - alert: NoOrdersReceived
        expr: |
          (
            rate(orders_completed_total[30m]) == 0
            and
            hour() >= 9 and hour() <= 22
          )
        for: 5m
        labels:
          severity: critical
          team: business
        annotations:
          summary: "No orders completed in last 30 minutes during business hours"
          runbook_url: "https://wiki.company.com/runbooks/no-orders"

      - alert: ConversionDropped
        expr: |
          rate(orders_completed_total[1h])
          /
          rate(cart_checkout_started_total[1h])
          < 0.3
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "Checkout conversion dropped to {{ $value | humanizePercentage }}"

      - alert: PaymentErrorRateHigh
        expr: |
          rate(payment_errors_total[5m]) > 0.5
        for: 3m
        labels:
          severity: critical
        annotations:
          summary: "{{ $value }} payment errors/sec — potential payment gateway issue"

Implementation via CloudWatch (AWS)

For AWS projects, we use CloudWatch. The code is instrumented via SDK (boto3) — sending OrdersCompleted and OrderRevenue metrics with dimensions PaymentMethod and Environment. Alerting rules are defined in Terraform:

resource "aws_cloudwatch_metric_alarm" "no_orders" {
  alarm_name          = "no-orders-30min"
  comparison_operator = "LessThanThreshold"
  evaluation_periods  = 1
  metric_name         = "OrdersCompleted"
  namespace           = "MyApp/Business"
  period              = 1800
  statistic           = "Sum"
  threshold           = 1
  treat_missing_data  = "breaching"

  dimensions = {
    Environment = "production"
  }

  alarm_description = "No orders in 30 minutes"
  alarm_actions     = [aws_sns_topic.critical_alerts.arn]
}

How to set up alerts for seasonal metrics?

Fixed thresholds work poorly for metrics with seasonality. On Friday evening, orders are 3 times higher than on Monday morning. CloudWatch Anomaly Detection builds a forecast based on historical data and triggers only when deviation exceeds the band. In our projects, this reduces false positives by 70%.

resource "aws_cloudwatch_metric_alarm" "orders_anomaly" {
  alarm_name          = "orders-anomaly"
  comparison_operator = "LessThanLowerOrGreaterThanUpperThreshold"
  evaluation_periods  = 2
  threshold_metric_id = "e1"

  metric_query {
    id          = "e1"
    expression  = "ANOMALY_DETECTION_BAND(m1, 2)"
    return_data = true
  }

  metric_query {
    id          = "m1"
    return_data = false
    metric {
      metric_name = "OrdersCompleted"
      namespace   = "MyApp/Business"
      period      = 300
      stat        = "Sum"
    }
  }
}

Routing business alerts

Business alerts should not wake developers at night. We configure routing via Alertmanager: alerts with label team=business and severity=critical go to Slack, while PaymentErrorRateHigh goes to PagerDuty, as it is a technical issue.

routes:
  - match:
      team: business
      severity: critical
    receiver: business-slack

  - match:
      team: business
      alertname: PaymentErrorRateHigh
    receiver: pagerduty-oncall

Why do business alerts produce false positives? How to fix it

False positives are the main headache of monitoring. They make you ignore warnings. A few rules:

• Use anomaly detection instead of fixed thresholds for metrics with seasonality.
• Add "for" time windows (e.g., 5 minutes) — short-term spikes won't trigger an alert.
• For non-critical alerts (conversion dropped by 10%), use low priority to avoid overloading the responsible persons.
• Regularly review alerts based on historical data and disable useless ones.

What is included in the work

• Instrumenting code with metrics (2–4 days)
• Setting up alerting rules and routing (1–2 days)
• Anomaly Detection for seasonal metrics (1 day)
• Business dashboard in Grafana (1–2 days)
• Documentation on metrics and alerts
• Training the team on business alerts
• Post-deploy support: 30 days of accompaniment

Process of work

1. Analytics — define business metrics and their baseline, choose the tool (Prometheus, CloudWatch, or other)
2. Instrumentation — add metrics to the code, configure export
3. Alerting rules — write rules considering seasonality and business priorities
4. Routing — configure notifications for different teams and times of day
5. Dashboard — create a business dashboard in Grafana with read-only access for the CEO
6. Test and deploy — test alerts on historical data, deploy to production

Implementation timelines

Contact us for a consultation. Order turnkey custom alerting implementation. We have experience setting up monitoring for e-commerce, SaaS, and content projects. We guarantee stable operation and adequate notifications without false positives.

Setup Web Analytics: GA4, GTM, Yandex.Metrica, and Amplitude

We often see: conversion rate 1.2%, traffic grows, but conversion stays flat. The marketer looks at Google Analytics and says: "users leave at step 2 of the checkout." The developer opens the same step — no errors, Sentry is silent. So it's not a JS bug, but a UX issue or skewed data from analytics. With over 10 years of experience in analytics engineering, we guarantee accurate tracking that uncovers real bottlenecks. Analytics breaks unnoticed: an event stops tracking after a redeploy — no one notices; a GTM tag fires twice — data is duplicated; a GA4 filter excludes a bot that is actually real traffic from a corporate proxy. An audit of your current tags will find the cause within a week.

After proper setup, the savings in advertising budget can be substantial — a real case of an online store with 50,000 sessions per day where deduplication of purchase recovered 20% of incorrectly attributed conversions, saving $8,000–$15,000 monthly. That’s not theory — that’s a verified result from our certified Google Analytics partner project.

Why do GA4 events duplicate and how to fix it?

Universal Analytics is gone, replaced by GA4's event-based model. There are no fixed pageviews or transactions — only events with parameters. This is more flexible but requires proper event design. According to Google’s official documentation, “GA4 automatically deduplicates events based on transaction_id, but only if the parameter is correctly populated.” Many implementations miss this.

Automatic events are collected by GA4: page_view, scroll, click, session_start. Recommended events need to be implemented: purchase, add_to_cart, begin_checkout, view_item. Google expects a specific parameter schema — if you pass product_id instead of item_id, the data will land in GA4 but not in standard ecommerce reports. Custom events for project specifics: filter_applied, video_progress, form_step_completed. Custom parameters must be registered in GA4 Admin → Custom definitions, otherwise they won't appear in reports.

A common mistake is the purchase event being duplicated. Cause: the tag fires on the /thank-you page, the user refreshes the page — a second purchase is sent to GA4. Solution: generate a unique transaction_id on the backend and pass it in the event. In our experience, 80% of e-commerce stores have this issue. GA4 deduplicates based on it (in theory — verify with DebugView). Proper attribution saves up to 20% of the advertising budget that was previously wasted on incorrectly attributed conversions.

How to set up the data layer to avoid data loss?

GTM is a tool for managing tags without code deployment. But "no code" doesn't mean "no architecture." The data layer is the foundation. We pass data from the application to GTM via dataLayer.push(). Structure: event + contextual data. For e-commerce: before opening a product page — push with product data. GTM tag reads from the data layer, not from the DOM.

window.dataLayer = window.dataLayer || [];
dataLayer.push({
  event: 'view_item',
  ecommerce: {
    items: [{
      item_id: 'SKU-12345',
      item_name: 'Product name',
      price: 1990.00,
      currency: 'USD'
    }]
  }
});

Bad practice: GTM tag parses the DOM — looks for the price in span.price, the name in h1. This breaks with any layout change. Good practice: always use the data layer. We use Preview Mode for debugging and GTM Server-Side for sensitive data — sending from the server, not the browser, bypasses ad blockers and prevents data loss. A properly implemented data layer reduces tracking errors by 95%.

How does Yandex.Metrica complement web analytics?

For a Russian audience, Metrica is a must — especially Webvisor. Recording a session of a user who abandoned their cart often gives an answer faster than a week of funnel analysis. Goals in Metrica: event-based (via ym(COUNTER_ID, 'reachGoal', 'GOAL_NAME')) or automatic (button click, page visit). Integration with CRM via Metrica Plus — passing offline conversions. Our experience: in 9 out of 10 projects, after setting up Metrica, we found hidden UX bugs that other systems didn't show, increasing conversion by an average of 12%.

What does product analytics give in Amplitude?

Amplitude is a product tool, unlike marketing-oriented GA4 and Metrica. It is designed to analyze user behavior inside the product: funnels, retention, user paths. Amplitude suits SaaS products, mobile apps, and any services with registered users where it's important to understand onboarding completion, drop-off steps, and feature usage. Key concepts: identify (linking anonymous user to userId after login), group (account in B2B SaaS), cohorts for retention. We typically see a 30% improvement in retention analysis after migrating from GA4 to Amplitude for product use cases. Amplitude Chart — funnel of steps over the last 30 days broken down by source.

Monitoring Data Quality

Analytics without monitoring is a black box. We set up:

• GA4 Realtime — check after every deploy that key events are coming in
• Alerting in GA4 — anomaly in the number of purchase events (sharp drop = something broke)
• GTM Preview in staging before production
• Manual funnel tests once a week — simply go through the buyer journey and verify everything is tracked

What the work includes

Process and timeline

1. Audit of existing tags and data (2 days)
2. Event schema design (2 days)
3. Data layer development and tag setup (3–5 days)
4. QA in Preview Mode and staging (2 days)
5. Deploy and dashboard setup (1 day)

Cost is calculated individually. Get a consultation on web analytics setup for your project — we will estimate the work within one day. Contact us to get started with a free audit of your current tracking.