I’d start with one developer problem - and a guide that helps solve it before a sales call. Show exactly what your OpenTelemetry support covers, how to send the first trace, and what migration and usage will cost.
Here’s the approach I’d use:
- Prove technical fit: Match each buyer’s task to tested capabilities and stated limits.
- Make evaluation self-service: Provide a quickstart, migration steps, rollback instructions, and an editable cost worksheet.
- Distribute by task: Use daily.dev Ads, community resources, and events to reach developers facing that problem.
- Measure working telemetry: Track setup, first data received, and completed evaluations - not just clicks.
My rule: first telemetry is activation, not success. Success means the evaluator can finish a task, such as diagnosing a failed request. That’s what I’d use to judge the campaign and decide what to test next.
1. Define your buyer and verify technical fit
Match each buyer to a specific problem
Separate the technical reviewer from the budget owner. An SRE may test investigation workflows, while an engineering leader checks spending and rollout risk. Use the guide on how to reach DevOps and platform engineers to segment buyers by tech stack, seniority, geography, and interests.
Choose one primary problem per campaign. The buyer’s task determines what the ad needs to prove: debugging, instrumentation, or rollout safety. Match your landing-page evidence to that task:
| Primary buyer | Campaign problem | Evidence to show |
|---|---|---|
| SRE | Noisy alerts or slow investigations | Alert context, service ownership, and a trace-to-log investigation |
| Platform engineer | Inconsistent instrumentation | Supported SDKs, deployment configurations, and centralized policy controls |
| Engineering leader | Unpredictable spending or migration risk | Cost drivers, rollout stages, security details, and portability limits |
Build the brief around one technical outcome and one adoption barrier. Then choose a matching conversion: deploying a Collector, sending the first trace, or requesting a technical evaluation.
Check incident reviews and support tickets to confirm the problem. Don’t assume every team needs another dashboard. The problem should also guide exactly what OpenTelemetry proof you show.
Specify what OpenTelemetry support includes
Publish a support matrix with links to the relevant OpenTelemetry documentation. Include signals, language SDKs, OTLP over HTTP or gRPC, Collector components and versions, deployment models, and export destinations. Clearly label each capability’s maturity.
Date the matrix and list tested versions. Accepting telemetry isn’t the same as making it searchable, correlated, and ready for alerts. The OpenTelemetry Collector receives, processes, and exports telemetry. Spell out which tasks the customer still owns: filtering, sampling, redaction, retention, and access control.
Place limitations beside the capabilities they affect. State whether an evaluator needs a separate log pipeline, an existing agent, or additional configuration. Use those details from the matrix to shape your quickstart and migration guides.
2. Create quickstart, migration, and cost guides
Use the quickstart as your demo
Build the quickstart around the exact capabilities and limits in the support matrix. Let evaluators get telemetry working without a sales call. Provide prerequisites, a sample application, and tested commands they can copy for installation, authentication, export, and startup.
Show expected output at each checkpoint: telemetry received, service visible, and deployment attributes attached. State whether the guide uses zero-code or code-based instrumentation. Explain the trade-off between fast setup and deeper application insight.
Include a failure evaluators can reproduce, along with the exact alert query, threshold, evaluation window, and notification destination. Show how to check that the alert links to the affected service and resolves after recovery.
Cover troubleshooting for missing data, rejected credentials, and exporter timeouts. Follow that with cleanup and rollback instructions. Measure completed setup steps, not claimed setup time.
Document migration steps and limits
Use the quickstart result as the migration baseline. Explain which OpenTelemetry instrumentation stays in place and which endpoints, exporters, or routing rules need to change.
Start in a sandbox, move to one low-risk service, then test a representative production service before rolling out to more services. Where supported, send telemetry to both destinations during validation and account for the extra volume.
Assign one owner to compare trace continuity, metric names and units, log correlation, dashboards, and alerts over the same time window. Keep the previous route available until the acceptance criteria pass. Clearly flag dashboard rewrites, query changes, unsupported features, and historical data that won't transfer.
Explain how observability costs work
Define what the product actually bills for. Separate ingested data from retained data, metric series, query usage, and export volume. Link each charge to current public billing documentation, and explain retention by signal, commitments, and overages where they apply.
Show how unbounded request IDs or URLs increase metric cardinality, and explain what sampling drops. Keep platform charges separate from Collector compute, storage, and network transfer.
Provide an editable workload worksheet covering requests per second, spans per request, retained sampling fraction, log size, metric-series count, retention, environments, and exports. Use this formula:
daily retained spans = requests per day × spans per request × retained sampling fraction
Label sample inputs hypothetical and ask evaluators to replace them with measured workload data. Let buyers change sampling, retention, cardinality, and traffic independently. Don't publish an unsupported savings estimate.
3. Distribute technical content with daily.dev Ads
Once your quickstart, migration, and cost guides are ready, use daily.dev Ads to put them in front of developers working on those problems. Keep each campaign focused on one task, with an ad promise, audience, and landing page that line up.
Choose a format for your campaign
Choose the format that fits your guide and what you want readers to do next.
| Campaign need | Format and product information | Content and next action |
|---|---|---|
| Get evaluators into a practical task | In-Feed Native Ads: sponsored cards in the personalized feed | Quickstart or migration guide → run the guide |
| Explain an architecture in depth | Sponsored Post: guaranteed feed impressions with a read-floor commitment and canonical republishing | Architecture walkthrough → read the implementation details |
| Build contextual visibility | Engagement Ads: Branded Tags, Keyword Spotlights, Custom Upvotes, Tag Page Takeovers, and Stack Placements | Relevant instrumentation or reliability resource → explore the guide |
| Reach readers through a relevant topic track | Digest newsletter sponsorships by topic track | Infrastructure or cost explainer → open the worksheet |
A Sponsored Post doesn't guarantee signups. Measure whether it moves readers further into evaluation.
Match targeting and messaging to the task
With your format chosen, narrow the audience to the exact buyer task. Keep SRE investigation campaigns separate from platform instrumentation and governance campaigns. Give each audience the one resource that addresses its problem, and apply geographic targeting when regional availability matters.
Use the same three elements in your ad and landing page: a problem-specific promise, a technical qualifier, and one next action. For audience planning, see the guide to reaching DevOps and platform engineers.
Share resources through communities and events
Treat observability Slack communities as places to help, not channels for bulk promotion. Follow each group's self-promotion rules. Before sharing a relevant guide, contribute troubleshooting lessons, implementation notes, or reusable resources. Those conversations can also point to objections and gaps in your documentation.
Use conversations and workshops at KubeCon + CloudNativeCon to test how you explain OpenTelemetry and observability. Turn questions that come up repeatedly into follow-up resources.
4. Measure activation and improve the campaign
Track progress from content to working telemetry
Once your docs help developers start setup, track whether they reach working telemetry. Measure documentation visits, quickstart starts, completed installs, first telemetry received, successful evaluations, and sales-qualified opportunities.
First telemetry received marks activation - not success. Define evaluation success around the buyer’s task, such as diagnosing a failed request or validating a representative service.
Tag each event with a timestamp, campaign and documentation IDs, tech stack, and a consent-approved company or account ID. Keep both first- and last-touch attribution. Set your reporting window before launch - for example, 30 days for activation.
Report developer progress separately from account-level buying progress. Also check whether activated accounts come back to use the product.
Use evaluation drop-offs to choose your next test
Once you’ve checked that tracking works, review conversion between stages each week. Use drop-offs to decide what to test:
- Landing-page exits suggest a mismatch in messaging or audience.
- Install failures point to setup, permissions, or export issues.
- Migration stalls point to compatibility gaps.
- Cost-estimation drop-offs suggest unclear ingestion or retention assumptions.
Test one variable at a time against your current baseline. Before launching each test, record the audience, dates, sample size, and success criterion. Judge a revised quickstart by working telemetry, not extra page views.
Review your launch checklist
Before increasing spend, confirm that you have a clear buyer problem, verified OpenTelemetry claims, a working quickstart, documented migration limits, transparent cost guidance, and tested activation events.
Assign owners to handle tracking failures and follow up on qualified accounts. Use the guide on reaching DevOps and platform engineers to plan distribution. Once those pieces are ready, discuss a daily.dev Ads campaign.
FAQs
How can I differentiate my tool beyond OpenTelemetry support?
Show SLO-backed reliability, not just compatibility. Explain which incidents your tool prevents, which runbook steps it eliminates, and what availability targets teams can measure. Walk through the golden path with actual dashboards and self-serve setup that takes Kubernetes complexity out of the process.
For SRE and platform engineers, build trust by spelling out what’s open, what’s portable, and how to leave. Make costs and migration guidance part of your docs-first demo.
How should I split campaign spend between SREs and platform engineers?
Don’t divide ad spend by job title alone. Focus on workflows: SREs prioritize reliability, incident response, and error budgets. Platform engineers focus on golden paths and developer experience.
With daily.dev Ads, target relevant tech stacks and interests, such as Kubernetes and observability. Put budget behind technical proof: incident write-ups for SREs and templates for platform engineers. Measure success through activation metrics, not audience splits.
When should sales engage a self-service evaluator?
Sales should step in when a self-service evaluator moves from individual use to company-wide adoption. Developers prefer to handle discovery, evaluation, and trials on their own. But as usage spreads across the company, they need help with procurement, security, compliance, or management approvals.
Focus on these high-intent moments to help internal champions who are already using the tool successfully.