惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

GbyAI
GbyAI
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
博客园 - 叶小钗
大猫的无限游戏
大猫的无限游戏
H
Help Net Security
G
Google Developers Blog
D
Docker
阮一峰的网络日志
阮一峰的网络日志
A
About on SuperTechFans
aimingoo的专栏
aimingoo的专栏
博客园 - 聂微东
Hugging Face - Blog
Hugging Face - Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
Apple Machine Learning Research
Apple Machine Learning Research
云风的 BLOG
云风的 BLOG
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
腾讯CDC
T
The Blog of Author Tim Ferriss
Microsoft Security Blog
Microsoft Security Blog
WordPress大学
WordPress大学
I
InfoQ
Engineering at Meta
Engineering at Meta
Stack Overflow Blog
Stack Overflow Blog
Google DeepMind News
Google DeepMind News

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
I Rewrote Our Instagram Transcript Actor for Pay-Per-Even...
SIÁN Agency · 2026-06-25 · via DEV Community
Cover image for I Rewrote Our Instagram Transcript Actor for Pay-Per-Event Pricing. The Economics Flipped.

SIÁN Agency

TL;DR — Moved an Instagram transcript actor from pay-per-result to pay-per-event billing. Three events, not one number. Margin held, retries stopped silently bleeding cash, and the actor is now honest about what it's actually charging for. If your scraper has a "credits" tab in the README, this is for you.

For a year I shipped scrapers the same way everyone does: one big knob — pay-per-result, $X per item, computed at the end of the run. It looked clean from the README. It was a mess underneath.

The actor would start, spin up a browser, hit Instagram, run into a transient block, retry, succeed on three out of ten URLs, and spit back a number. The user paid for three. We absorbed the cost of the seven retries, the cold start, and the GPU minutes the transcription model burned on partial audio. On a good week the unit economics worked. On a bad week — when Instagram changed something and our success rate dropped to 60% — we paid Apify and OpenAI for the privilege of running a free service.

That's the trap pay-per-result puts you in. Your price is fixed. Your cost isn't.

The teardown

Pay-per-result conflates three different things into one transaction:

  1. Setup work — booting the actor, validating input, warming the browser. Happens once per run regardless of how many URLs you pass.
  2. Per-item work — fetching the post, extracting media, calling the transcription model. Scales linearly with input.
  3. Optional premium work — the fast-processing path that costs us more per item but the user explicitly asked for.

Charging one rate for "a result" forces you to subsidise items #1 and #3 out of the margin on item #2. When users bulk-submit URLs, item #1 amortises and you're fine. When they submit one URL at a time, you eat the setup cost on every run. When they enable fast processing on every call, you eat the premium delta on every call.

Apify's pay-per-event model lets you charge for each of these separately. So we did.

The replacement pattern

The new actor declares three events in actor.json:

"monetization": {
  "events": [
    { "name": "ActorRunStarted",            "price": 0.005 },
    { "name": "InstagramContentProcessed",  "price": 0.018 },
    { "name": "FastProcessingUpgrade",      "price": 0.002 }
  ]
}

Then in the actor body, you charge against those events at the moment the work is actually done:

import { Actor } from 'apify';
await Actor.init();

await Actor.charge({ eventName: 'ActorRunStarted' });

for (const url of input.bulkUrls) {
  try {
    const result = await processInstagramPost(url, input.fastProcessing);
    await Dataset.pushData(result);

    // Only charge per item on success.
    await Actor.charge({ eventName: 'InstagramContentProcessed' });

    if (input.fastProcessing) {
      await Actor.charge({ eventName: 'FastProcessingUpgrade' });
    }
  } catch (err) {
    // Failed items don't bill the user. They also don't bleed margin
    // because the run-started fee already covered the setup.
    log.warning(`Skipping ${url}: ${err.message}`);
  }
}

await Actor.exit();

Three lines of policy:

  • Run starts always bill. $0.005 covers boot. Doesn't matter if zero items succeed.
  • Per-item billing only fires after pushData. Failures are free for the user — and free of margin loss for us, because we already covered fixed cost.
  • Premium path bills on top. If the user opted into fast processing, that delta is charged separately and visibly.

Fig. 1 — Three billing events per run. Setup, per-item, and optional premium are charged separately.

Result

Three months in:

  • Margin per run stopped going negative on small-batch / high-failure runs. The run-started fee acts as a floor.
  • Failed-URL ratio dropped from 12% to 4% — not because we got better, but because we stopped hiding failures behind a flat result fee. Users started reporting bad URLs in support, instead of opening refund tickets.
  • Average revenue per user went up, not down, even though our headline price ($0.018/item) was lower than the previous flat $0.025. Setup fee + opt-in premium fee made up the difference.

Cleaner pricing, cleaner margin, cleaner conversation with users about what they're actually paying for.

If you're running an Apify actor on flat pay-per-result and your retry rate is anything above noise, you're subsidising the unreliable part of your stack. Move the line. Charge for what you do, not for what survives. The Instagram actor I rewrote with this model is live at Instagram AI Transcript Extractor — same shape applied across the rest of our actor portfolio over the last quarter.

What event are you not charging for that you should be? Drop the actor in the comments — I'll look at the schema.


Written by **Jonas Keller, Senior Automation Architect at SIÁN Agency. Find more from Jonas on dev.to. For custom scraping or automation work, hire SIÁN Agency.