High-Speed E-Commerce Competitor Price & Stock Tracker -> Telegram Alerts (Apify + n8n)

# :rocket: Hochgeschwindigkeits-E-Commerce-Konkurrenz-Preis- und Lagerverfolgung → Telegram-Benachrichtigungen (Apify + n8n)

Hallo zusammen! :waving_hand:

Ich habe ein produktionsreifes n8n-Workflow + Apify-Actor-Setup erstellt, das Preisrückgänge und Ausverkaufsereignisse von Konkurrenten im E-Commerce über Shopify, WooCommerce, Salesforce Commerce Cloud, Magento und D2C-Brand-Stores verfolgt und sofortige formatierte Markdown-Benachrichtigungen direkt an Telegram (oder Discord/Slack) sendet.

Traditionale SaaS-Tools wie Prisync kosten über 200 $/Monat, und intensive Puppeteer-Scraper verbrauchen massiv RAM. Dieses Setup nutzt eine leichte HTTP/JSON-LD-Engine (die nur etwa 90 MB RAM verbraucht), was es ultraschnell und äußerst kosteneffektiv macht.

-–

## :high_voltage: Was dieser Workflow tut

  1. Überwacht E-Commerce-URLs: Verfolgt Preisrückgänge, Preiserhöhungen und Bestandsstatusänderungen (Im Bestand ↔ Ausverkauft).

  2. Statusbezogener Vergleich: Löst Benachrichtigungen nur aus, wenn eine tatsächliche Preis- oder Bestandsänderung auftritt (ignoriert redundante Durchläufe).

  3. Sofortige Telegram-Benachrichtigungen: Sendet wunderschöne Markdown-Nachrichten mit Emojis, Preisvarianten (alt vs. neu) und direkten Produktlinks.

-–

## :package: Copy-Paste-n8n-Workflow-Vorlage

Kopieren Sie den JSON-Code unten und fügen Sie ihn direkt in Ihre n8n-Workflow-Canvas ein (`Strg+V` oder `Cmd+V`):

```json

{

“name”: “E-Commerce Price & Stock Monitor to Telegram”,

“nodes”: [

{

  "parameters": {

    "httpMethod": "POST",

    "path": "ecommerce-price-alert",

    "options": {}

  },

  "name": "Apify Webhook Trigger",

  "type": "n8n-nodes-base.webhook",

  "typeVersion": 1,

  "position": \[250, 300\]

},

{

  "parameters": {

    "conditions": {

      "boolean": \[

        {

          "value1": "={{ $json.body.totalAlerts > 0 }}",

          "value2": true

        }

      \]

    }

  },

  "name": "Has Price/Stock Alerts?",

  "type": "n8n-nodes-base.if",

  "typeVersion": 1,

  "position": \[470, 300\]

},

{

  "parameters": {

    "chatId": "YOUR_TELEGRAM_CHAT_ID",

    "text": "={{ $json.body.formattedText }}",

    "additionalFields": {

      "parse_mode": "Markdown"

    }

  },

  "name": "Send Telegram Alert",

  "type": "n8n-nodes-base.telegram",

  "typeVersion": 1,

  "position": \[690, 200\]

}

],

“connections”: {

"Apify Webhook Trigger": {

  "main": \[

    \[

      {

        "node": "Has Price/Stock Alerts?",

        "type": "main",

        "index": 0

      }

    \]

  \]

},

"Has Price/Stock Alerts?": {

  "main": \[

    \[

      {

        "node": "Send Telegram Alert",

        "type": "main",

        "index": 0

      }

    \]

  \]

}

}

}

```

-–

## :gear: 3-Schritte-Anleitung

### Schritt 1: Workflow in n8n importieren

  1. Erstellen Sie einen neuen Workflow in n8n.

  2. Kopieren Sie das obige JSON-Snippet und fügen Sie es (`Strg+V`) in Ihren n8n-Editor ein.

  3. Speichern Sie den Workflow und schalten Sie den Aktiv-Schalter auf AN (Entscheidend: Stellen Sie sicher, dass Sie die Produktions-Webhook-URL verwenden, nicht die Test-URL!).

### Schritt 2: Apify-Actor konfigurieren

  1. Öffnen Sie den Smart E-Commerce Price & Stock Monitor Actor auf Apify.

  2. Fügen Sie die E-Commerce-Produkt-URLs, die Sie verfolgen möchten, unter Zu überwachende Produkt-URLs ein.

  3. Kopieren Sie Ihre n8n-Produktions-Webhook-URL und fügen Sie sie unter Webhook-Ziel-URL ein.

### Schritt 3: Telegram verbinden

  1. Ersetzen Sie `YOUR_TELEGRAM_CHAT_ID` im n8n-Telegram-Knoten durch Ihre tatsächliche Telegram-Chat-ID oder Kanal-ID.

  2. Klicken Sie in Apify auf Start oder planen Sie es so, dass es alle 6–12 Stunden ausgeführt wird!

-–

## :hammer_and_wrench: Tech-Stack und Funktionen

  • Engine: `got-scraping` + `CheerioCrawler` (Kein schwerer Chrome/Puppeteer-Overhead).

  • Auto-Erkennung: Schema.org JSON-LD-Mikrodaten-Parsing + 25+ CSS-Fallback-Selektoren.

  • Sicherheit: Integrierter Anti-SSRF-Schutz für private IP-Adressen und optionale HMAC-SHA256-Request-Signaturen.

Ich hoffe, dieser Workflow hilft Agentur-Eigentümern und E-Commerce-Managern, die Konkurrenzüberwachung zu automatisieren! Lassen Sie mich wissen, wenn Sie Fragen oder Feedback haben.

Schöner Artikel. Der RAM-Vergleich gegenüber Puppeteer-Setups ist der Teil, den die meisten Menschen unterschätzen.

Drei Dinge, die dazu neigen, dieses Muster nach ein paar Wochen Laufzeit zu beißen, falls sie nützlich sind:

Webseiten ändern ihre JSON-LD ohne Vorwarnung. Ein Shop wechselt Themes oder verschiebt den Preis in ein verschachteltes Offers-Array, dein Parser gibt null zurück, und der Workflow wird weiterhin erfolgreich durchgeführt, enthält aber nichts. Es lohnt sich, eine Überprüfung hinzuzufügen, die laut fehlschlägt, wenn ein Scrape null Produkte zurückgibt, anstatt es stillschweigend durchzulassen.

Doppelte Benachrichtigungen. Wenn ein Produkt um einen Schwellwert schwebt, können Sie die gleiche Preissenkung mehrmals pro Stunde an Telegram senden. Das Speichern eines Hash aus Produkt plus Preis und das Überspringen von allem, das Sie bereits an diesem Tag gesendet haben, behebt das meiste.

Ratenbegrenzung pro Domain anstelle von global. Ein langsamer Shop kann den gesamten Durchlauf blockieren, wenn alles eine einzige Warteschlange teilt.

Wie gehen Sie mit Stores um, die den Preis nur auf der Client-Seite rendern? Das ist normalerweise dort, wo der leichte HTTP-Ansatz aufhört zu funktionieren und die Leute auf einen Browser zurückfallen, was den RAM-Vorteil zunichte macht.

Danke für die detaillierte Aufschlüsselung @Cloudrocket! Du hast völlig recht — diese 4 Spezialfälle sind normalerweise das, was Scraper in der Produktion nach ein paar Wochen zum Scheitern bringt.

Ich habe den Actor tatsächlich verfeinert, um genau diese Punkte zu handhaben:

  1. Schema-Änderungen: Falls JSON-LD ausfällt, greift er auf ~25 CSS-Selektoren zurück. Ich habe auch eine “Lautstark fehlschlagen”-Prüfung hinzugefügt, damit er, wenn null gültige Produkte extrahiert werden, eine explizite Warnbenachrichtigung via Webhook abfeuert, statt stillschweigend vorbeizugehen.
  2. Warnflut: Ich habe MD5-Hash-Deduplizierung über 24h hinweg (URL + Preis + Bestand) zusätzlich zum Prozentsatzschwellwert hinzugefügt, sodass Preisfluktuationen Telegram nicht zuspammen.
  3. Queue-Stagnation: Crawlee verwaltet Pro-Domain-Verzögerungen (1,5s) nativ, sodass eine langsame Website den Rest der Queue nicht aufhält.
  4. SPAs: Es kennzeichnet jsRenderingRequired: true in der Ausgabe, wenn statisches Parsing Daten übersieht, sodass klar wird, wann ein Browser-Setup erforderlich ist.

Ich schätze es wirklich, dass Leute in der Community echte Herausforderungen aus der Praxis wie diese teilen. Falls du jemals die Gelegenheit hast, es auf Apify zu testen, würde ich mich sehr freuen, deine Gedanken zu erfahren!

Gute Fixes. Das deckt das meiste ab, das ich bei diesen Setups in der Produktion schief gehen sehe.

Eine kleine Sache zur Deduplizierung: URL + Preis + Bestand zu hashen bedeutet, dass ein echtes wiederholtes Ereignis innerhalb des 24-Stunden-Fensters verschluckt wird. Angenommen, ein Preis fällt, erholt sich ein paar Stunden lang und fällt dann wieder auf die gleiche Zahl. Der zweite Preisfall ist echte Neuigkeit für denjenigen, der zuschaue, aber er wird identisch gehashed wie der erste und übersprungen. Wenn man ein Richtungs-Flag oder einen groben Zeit-Bucket zum Hash hinzufügt, bleibt der Spamschutz erhalten, ohne diesen Fall zu verstecken.

Das jsRenderingRequired-Flag ist ein schöner Touch. Die meisten Scraper geben einfach Nulls zurück und lassen dich raten, ob der Parser kaputtgegangen ist oder die Seite tatsächlich einen Browser braucht.

Ich werde den Actor gegen ein paar Shops, die ich bereits beobachte, laufen lassen, wenn ich etwas Zeit habe, und poste Rückmeldung, falls etwas Interessantes dabei herauskommt.

Ah verdammt, guter Punkt zum Preis-Rebound. Habe völlig übersehen, dass ein Drop → Revert → Drop Szenario innerhalb von 24h vom Hash verschluckt würde.

Aktualisiere die Hash-Logik, um den Übergang (prevPrice->currentPrice) zu verfolgen, anstatt nur den Zielzustand zu betrachten, damit diese legitimen Alerts trotzdem durchgehen.

Danke, dass du das gefunden hast! Lass mich wissen, wie die Tests laufen, wenn du dazu kommst.