Viral-O-Meter for YouTube (Built with n8n + Bright Data)

Mohit Agnihotri — Sun, 31 Aug 2025 14:31:25 +0000

This is a submission for the AI Agents Challenge powered by n8n and Bright Data

What I Built

Viral-O-Meter for YouTube — an n8n + Bright Data agent that checks a keyword's viral potential in real time.

It pulls top YouTube results for a keyword via Bright Data’s Verified Node, normalizes metrics (views/likes/length), computes robust stats (median & p75 views, like rate, Shorts share, median lengths), and asks an AI Agent to deliver a GO/NO_GO verdict, recommended format (Shorts vs Long-form), ideal length band, content angles, and hooks.

Who it helps: creators & marketers who want a quick, data-driven green‑light before spending time on a video.

Demo

Video walkthrough: https://youtu.be/vJgj8UrPAmw
Live agent: https://dev-challenge-brightdata.app.n8n.cloud/form/trend-finder

n8n Workflow

Gist (workflow JSON): https://gist.github.com/mohitagnihotri/062a1cee13e30bcdeccba3aaa8895b61
Key nodes:
- Bright Data (Verified Node): Data Collector (trigger collection & fetch snapshot), Web Unlocker when needed.
- Code (Normalize): converts raw fields to numeric (views/likes), derives views_per_day, parses HH:MM:SS, classifies Shorts vs Long-form.
- Code (Stats): computes medians/quantiles and seeds a suggested length band (±20% around top‑quartile median).
- Agent (AI): consumes the enriched JSON and returns structured recommendations.
- Report: send proper analysis report to given email through Gmail.

Technical Implementation

High-level flow

Ingest with Bright Data
- Use Data Collector to collect YouTube search/results pages by keyword.
- Use Deliver Snapshot / Get Snapshot Content to fetch structured results.
- If regional blocks occur, enable Web Unlocker automatically in the Verified Node.
Normalize (Code Node #1)
- Parse numeric strings like “58,613”, “1.2M/1.2K” → integers.
- Parse video_length (seconds or HH:MM:SS) → length_seconds & length_hms.
- Derive views_per_day, compute like_rate_pct, detect post_type.
Stats (Code Node #2)
- Compute median / p75 for views, median like rate, Shorts share %.
- Compute median length (all) and median length among the top quartile by views.
- Create a recommended_seed with an anchor length (top‑quartile median) and a ±20% band; include a format_hint based on top performers.
AI Agent
- System Prompt: “You are a YouTube content viability analyst …” (uses benchmarks & recommended_seed if present; otherwise computes).
- User Prompt: “Analyze the following dataset … { JSON.stringify($json, null, 2) }”
- Output: deterministic JSON with verdict, confidence, recommended format/length, angles, hooks, and checklist.
Outputs
- Post reports to provided email through Gmail.

Design choices

No external assumptions: Agent reasons only over the provided dataset.
Robustness: use medians and quantiles to resist outliers.
Actionability: force the Agent to output clear ranges (seconds + mm:ss), angles, hooks, and checklist.

Bright Data Verified Node

Endpoints used: Data Collector (trigger & deliver snapshots), Web Unlocker when geo or bot blocks are detected.
Why Bright Data? Verified, production-ready node in n8n; handles real-time collection and anti-bot hurdles without brittle DIY scraping.
Schema highlights: title, url, views, likes, video_length, date_posted, channel, post_type, plus derived fields (views_per_day, like_rate_pct, length_seconds).
Cost control: run snapshots on-demand and cap concurrent collections; cache daily to reduce duplicate fetches.

Journey

What worked

Verified Node made collection straightforward; Deliver Snapshot gave predictable JSON.
Separating normalize and stats steps simplified prompt design and let the Agent stay lightweight.

Challenges

Mixed units & locales: views “K/M” + comma separators → solved via a single parser.
Shorts vs Long-form detection: use explicit post_type when present; fallback to <60s.
Recency bias: compute views_per_day to compare older vs newer videos fairly.

What I learned

Scrapping without tools like BrightData is not possible as IP gets blocked, get 403 error etc.
Learnt unfamiliar n8n nodes like Merge etc.
Framing the Agent’s output as strict JSON drives consistent downstream automation.
Anchoring recommended length to the top‑quartile median yields practical targets that mirror what performs best.

Latency Slayer: a Redis 8 semantic cache gateway that makes LLMs feel instant

Mohit Agnihotri — Sun, 10 Aug 2025 17:57:45 +0000

This is a submission for the Redis AI Challenge: Real-Time AI Innovators.

What I Built

Latency Slayer is a tiny Rust reverse-proxy that sits in front of any LLM API.

It uses embeddings + vector search in Redis 8 to detect “repeat-ish” prompts and return a cached answer instantly. New prompts are answered once by the LLM and stored with per-field TTLs, so only the response expires while metadata persists.

Why it matters: dramatically lower latency and cost, with transparent drop-in integration for any chat or RAG app.

Core tricks

Redis Query Engine + HNSW vectors (COSINE) to find semantically similar earlier prompts.
Hash field expiration (HSETEX / HGETEX) so we can expire just the “response” field without deleting the whole hash.
Redis Streams for real-time hit-rate & latency metrics, rendered in a tiny dashboard.

Demo

Video: https://youtu.be/lA-d4WO0Fjg
Repo: https://github.com/mohitagnihotri/latency_slayer

Screenshots:

How I Used Redis 8

Vector search (HNSW, COSINE) on a HASH document that stores an embedding field (FP32, 1536-d from OpenAI text-embedding-3-small).
Per-field TTL on hashes: HSETEX to set the response field and its TTL in a single step; HGETEX to read and optionally refresh TTLs. This gives granular cache lifetimes without deleting other fields (like usage or model metadata).
Redis Streams: XADD analytics:cache per request; the dashboard subscribes and renders hit rate, token savings, and latency deltas in real time.

Data model (simplified)

cache:{fingerprint} → Hash fields: prompt, resp, meta, usage, created_at (with resp having its own TTL)
vec:{fingerprint} → Vector field + tags (model, route, user)
Stream: analytics:cache with {event, hit, latency_ms, tokens_saved}

Why Redis 8?

New field-level expiration commands on hashes make cache lifecycle clean and safe.
New int8 vectors keep memory low and speed high.
Battle-tested Streams/PubSub give us real-time observability with a tiny footprint.

What’s next

Prefetch: predict likely next prompts and warm them proactively.
Hybrid filters: combine vector similarity + tags (model/route) for stricter cache hits.
Cold-start tuning: adapt hit threshold by route and user cohort.
Currently storing FP32 vectors for simplicity; INT8 quantization is planned to lower memory and speed up search

Forem: Mohit Agnihotri

Viral-O-Meter for YouTube (Built with n8n + Bright Data)

What I Built

Demo

n8n Workflow

Technical Implementation

Bright Data Verified Node

Journey

Latency Slayer: a Redis 8 semantic cache gateway that makes LLMs feel instant

What I Built

Demo

How I Used Redis 8

Data model (simplified)

Why Redis 8?

What’s next