Just wrote a practical guide on viewability for publishers who are looking for more than "just lazy load your ads" advice.

Here's the short version of what it covers:

1. Prioritise your header script and CMP. Every millisecond of delay pushes the entire render pipeline back. If your consent manager or header bidding script is loading behind other scripts, that's the first thing to fix.
2. Reduce initial load contention. Below-the-fold third-party content (commenting widgets, recommendation engines, social embeds) should not compete with your ad stack for initial load priority. On most publisher sites, they do.
3. Deal with sync pixel storms. Third-party widgets trigger cascades of user sync pixels that compete for JS execution time, including the execution time viewability measurement needs. An ad can be perfectly visible and still not register because the measurement script is contending with sync traffic from something the user hasn't even scrolled to.
4. Rethink Open Bidding. It adds latency at peak times and Google have said they can't make it faster. Whether the marginal revenue justifies the speed cost across every impression is worth testing.
5. Smarter ad refresh. Fixed-timer refresh is blunt. Viewport-limited refresh improves viewability but can reduce impressions. Bid-aware refresh (refreshing based on demand rather than a clock) is where the real gains are, and early testing suggests it can improve viewability and yield at the same time.

The full piece goes into the mechanics of why lazy loading often hurts viewability more than it helps (creative render timing, auction cost multiplication) and includes realworld render pipeline benchmarks. Link in comments.

Have any of you tested the APS prebid adapter? What were the results and learning from implementing ?

Hi all! Working on turning a website around. They currently run negotiated ad sales using Kevel. I want to add an exchange in the mix (SSP?) to monetize the unsold inventory (28m impressions/mo in the US).

Our adops consultancy is pushing us to sign up for Kevel Relay + PubMatic.

Is that the best/fastest way to get a POC live? Any other suggestions?

Anyone else noticied that selling Traffic has gotten increasingly worse? Every SSP now uses dofferent IVT Tools and the Number vary a lot. Adagio gives us 50% IVT through Adloox, other Demand Partners give us 10% IVT through Pixalate, some Partners report nothing through HUMAN. It's gotten increasingly harder to know what Traffic to send to who, everybody seems to have their own Benchmark of what IVT is now. Hope i'm not the only one.

Planning agency-side for a few years now and noodling on a side project idea and want a gut check before going further.

Genuinely curious:

- What part of your job would you pay real money out of pocket to make easier or go away?

- Any Excel monstrosity or Power Automate flow you’ve cobbled together that you wish was an actual product?

- $20/month personally for something that saved you 3 hours a week - would you actually pay? $50? $100?

Not selling anything, literally don’t have anything to sell yet. Just trying to figure out if what drives me nuts drives other people nuts too.

Google Ads & DV360 have been the revenue drivers for most of our ad units.

Suddenly last week the impressions being rendered by them dropped by over 90%.

While the overall delivery rates stayed the same as other bidders (criteo, liftoff, rtb house., etc) started winning but the eCPM & hence the revenue for that ad unit reduced by >70%.

Further context:

• it is a unified ad unit serving both banners and native ads
• there are no pricing rules applied to that ad unit currently

 

In the past we've seen drops but it generally recovered in a couple of day, but in this case it's almost been a week.

I checked both policy centre & app-ads.txt - no flags/issues there.

1. What should be the right action plan here?
2. Any data i should dig into?
3. How do i prevent this from happening with other ad units?

Hey, I'm pretty new on this but I founded a website like a week ago, this is my traffick, I decided to go with Adsterra and give it a try is this amount any good, or what do I need to do to get actual good revenue?

https://preview.redd.it/xu5tc651112h1.png?width=1624&format=png&auto=webp&s=c4fc944912d74011f0caeabc057162ab7c1c2791

https://preview.redd.it/8bakdi8b112h1.png?width=1800&format=png&auto=webp&s=247118e6181ecb59ce6bdbcb486fb297947c1ebe

And also using a player that has ads I have made this:

https://preview.redd.it/eu7divnh112h1.png?width=773&format=png&auto=webp&s=8f67c9efa863cc03c95b5c49db3208095c67849b

But idk... like what's the catch to make actual good money, because I don't think I'm that bad rn

https://preview.redd.it/ol7nqnqo112h1.png?width=1617&format=png&auto=webp&s=4bde2b1ced99b840ed2da0a10aa6b3ef6ca2c76a

Please let me know what I'm doing wrong, this website is +18 by the way

https://preview.redd.it/okuwd3umzu1h1.png?width=1280&format=png&auto=webp&s=4621053aaaa293409f9d119ea45fbb5252174ff6

I’ve been building a tool (ExplodingWeb.io) for a simple use case:

finding publishers with growing traffic but little or no visible ad monetization.

The reason I think this is useful for ad ops / monetization companies is obvious:

if a site is getting real traffic growth but still has no ads.txt footprint, very few ad relationships, or weak visible monetization signals, that can be a good publisher to contact and try to onboard.

That’s the main use case, but not the only one.

With it, you can also find:

- publishers with growing traffic and weak monetization setups

- sites that already run ads, but may be under-monetized

- ownerdomain groups, so one interesting site can lead to a bigger publisher group

- managerdomain groups, to see which management layers sit behind clusters of sites

- ad network / publisher combinations across many domains

- fast-growing domains, new domains, and ad-supported sites from one explorer

- single-domain pages with traffic trend, ads.txt status, and related group data

I’m curious from the ad ops / publisher side:

- if you were prospecting publishers, which signals would matter most to you first?

- how useful is “growing traffic + no visible monetization” as an outreach filter?

- what else would you want to see before reaching out to a publisher?

I am currently running ads from USA with my personal account and home wifi IP address. I spend $100k+ per month on ads.

I will be in Europe for 8 weeks, traveling many countries and changing cities very often. So now, I am looking into remote setups. Money is not a concern as this would be a business expense for me.

Options:
Option #1: PiKvm + Tailscale for home Mac. Then use a travel device to remote into the home Mac.

The risk with this option is I will have a single point of failure i.e. the session on home Mac. If that session ends and FB asks me to verify on my iPhone during new login, I won't be able to because iPhone will have Europe IP address.

Option #2: Remote desktop with Anydesk / Chrome Remote Desktop

The risk with this option is if my home mac shuts down. These softwares (unlike PiKVM) do not work when the Mac is locked with password during reboot.

Option #3: Replacement router at home with VPN server function

The risk is VPN leak / location mismatch / timezone mismatch / maybe other things that I am not aware of because I have not fully researched this so would appreciate insights.

Option #4: Any suggestions?

Since my last Post about this got a few People speculating about how good my homemade IVT Detection actually is (and one of my detections making a bit of a fool out of himself in the process) I decided to make a little Walkthrough through all the different Modules I have built.

The Probe on the User Side
The publisher-side snippet is ~30 KB minified and runs as a single async init() on page load. It collects signals in parallel from 15 specialised probes, ships one main beacon ~200 ms later, and follows up with two delayed supplemental beacons (Prebid auction + NSFW image scan). Everything is read-only - no DOM mutation, no script injection into 3p frames.

• Mouse - passive listeners count movements & clicks, compute path length, linearity, speed, and click intervals. Ruler-straight paths and constant inter-click gaps flag bots.
• Keyboard - counts keystrokes and watches for typing into hidden form fields (credential-stuffing tell).
• Viewport - screen + window dimensions, devicePixelRatio, color depth, orientation, visibility state, and whether the page is running inside an iframe.
• Browser - UA, vendor, platform, languages, plugin list, and headless tells (navigator.webdriver, _phantom, __nightmare, missing chrome.runtime, etc.).
• Device - CPU cores, RAM, touch points, Battery API (if applicable), and WebGL GPU vendor/renderer (the strongest single hardware ID). Catches "mobile UA on a Linux desktop with no touch" emulation mismatches.
• Network - connection type, downlink, RTT, save-data flag, online state, plus high-entropy User-Agent Client Hints (arch, model, platform version).
• Page - referrer, title, URL, iframe/script/DOM-node/form counts, and number of hidden elements. Spots pages with no real content but hundreds of ad scripts.
• Timing - PerformanceNavigationTiming: load time, DCL, DNS, TCP, TTFB, transfer size, redirect count, resource count. Bots and pre-renderers have unmistakable timing shapes.
• Session storage - capability probe for cookies, localStorage, sessionStorage, IndexedDB, plus quota. Anti-detect browsers often sandbox or disable storage.
• Content - scans the page's RTA meta tag, URL, title, and ad-network scripts for adult-content signals (used to catch publishers misrepresenting their inventory).
• Ad slots - walks every ad container, measures geometry, viewport overlap, computed visibility/opacity, stacking context, and iframe nesting. Surfaces zero-size, off-screen, hidden, and stuffed iframes.
• Auction (delayed) - polls for Prebid / APS / RTD modules, reads winning bids, bidder codes, CPMs, and any audience segments injected into the auction. Also detects DMP/CDP scripts (LiveRamp, Permutive, BlueKai, etc.) by hostname.
• Cookies - reads document.cookie and matches names against a curated list of DMP / identity-graph providers, flagging high-value intent segments (finance, auto, B2B, pharma) that command $15+ CPMs.
• Consent - inspects the TCF v2 / IAB GPP CMP, detects auto-accept scripts, and flags localStorage fingerprints of consent-stuffing libraries.
• NSFW (delayed) - lazy-loads a TensorFlow.js MobileNetV2 model and classifies visible images on the page (drawing / neutral / sexy / hentai / porn) to catch adult content on inventory declared as brand-safe.

The Modules indicating High Fraud

• H001 Detects browsers controlled via the WebDriver automation protocol.
• H002 Detects headless browser environments such as headless Chrome.
• H003 Detects legacy PhantomJS / QtWebKit headless runtimes.
• H004 Detects Selenium, ChromeDriver, and GeckoDriver injections.
• H005 Detects Puppeteer and CDP-based automation including stealth plugins.
• H006 Detects Playwright automation across all three browser engines.
• H007 Detects CasperJS automation stacks.
• H008 Detects NightmareJS / Electron automation including Node API leaks.
• H009 Detects generic non-human traffic from HTTP-client UAs and behavioral absence.
• H010 Detects crawler UAs and verifies them via reverse DNS, flagging impersonators.
• H011 Detects click farms via click rate, interval consistency, geo mismatch, and session repetition.
• H012 Detects programmatic click injection with sub-human timing and missing pointer trails.
• H013 Detects spatially injected clicks at origin coordinates with no pointer lifecycle.
• H014 Detects ad-targeted click spamming and budget-exhaustion patterns.
• H015 Detects ghost clicks that lack the mousedown/mouseup lifecycle.
• H016 Detects click stacking via overlapping ad iframes and z-index anomalies.
• H017 Detects network-level ad request and impression-pixel flooding.
• H018 Detects automated clicking with timer-precision intervals and geometric mouse paths.
• H019 Detects click redirection fraud across deep domain-hopping redirect chains.
• H020 Detects clicks on CSS-invisible elements and hidden iframes.
• H021 Detects pixel stuffing via near-zero container sizes claiming impressions.
• H022 Detects ad stacking where multiple ads share the same on-screen coordinates.
• H023 Detects iframe stuffing via content / size mismatch and undeclared ad content.
• H024 Detects off-screen ad rendering with CSS positioning outside the viewport.
• H025 Detects zero-size ads claiming impressions.
• H026 Detects CSS-level ad hiding with opacity 0, visibility hidden, or overflow clipping.
• H027 Detects impressions fired while the tab is in the background or never became visible.
• H028 Detects viewability metric manipulation against the MRC standard.
• H029 Detects auto-refresh impression fraud via meta refresh, programmatic reloads, and slot-refresh API abuse.
• H030 Detects pop-under fraud via never-visible popups, gestureless window.open, and immediate blur.
• H031 Detects data center traffic via ASN lookup and near-zero RTT.
• H032 Detects proxy traffic via proxy headers, WebRTC IP leak mismatch, and threat-intel classification.
• H033 Detects VPN traffic via DNS resolver geo leak and timezone or locale inconsistency.
• H034 Detects Tor traffic via exit-node lookup and Tor Browser fingerprint patterns.
• H035 Detects residential proxy networks via IP rotation against a stable fingerprint.
• H036 Detects traffic laundering through high-risk TLD referrers and known broker UTM sources.
• H037 Detects domain spoofing via ads.txt or sellers.json violations and bid-request mismatch.
• H038 Detects URL masking and click-URL cloaking between scanner and user.
• H039 Detects referrer spoofing via NXDOMAIN, newly registered domains, and timing inconsistencies.
• H040 Detects traffic brokering via unauthorized sellers.json chains and excessive supply hops.
• H041 Detects Chrome DevTools device emulation via touch and dimension inconsistencies.
• H042 Detects fake user agents through Client Hints, V8 version, and platform impossibilities.
• H043 Detects canvas fingerprint spoofing via per-render noise injection and known anti-detect hashes.
• H044 Detects WebGL spoofing via patched getParameter and impossible OS / GPU combinations.
• H045 Detects timezone spoofing via Date and Intl mismatch against IP geolocation.
• H046 Detects language spoofing via Accept-Language vs navigator.languages disagreement.
• H047 Detects screen resolution spoofing via impossible viewport / screen relationships and DPR values.
• H048 Detects platform spoofing via navigator.platform getter patching and oscpu contradictions.
• H049 Detects fake touch implementations on devices with no real touch hardware.
• H050 Detects hardware spoofing via patched hardwareConcurrency or deviceMemory getters.
• H051 Detects trojan-infected browsers via malware-IP feeds, C2 beacons, and post-load DOM mutation.
• H052 Detects adware injecting unauthorized ad tags from browser extensions.
• H053 Detects browser extension fraud where extensions inject or modify ad slots.
• H054 Detects malicious browser extensions running keyloggers or credential scrapers.
• H055 Detects extensions that hijack cookies or session storage for credential theft.
• H056 Detects extensions that overlay or replace publisher ad creatives.
• H057 Detects extensions blocking publisher anti-fraud scripts.
• H058 Detects injected scripts loaded post-DOMContentLoaded from unauthorized origins.
• H059 Detects malicious code-eval patterns inside ad creatives and ad tags.
• H060 Detects DOM hijacking via overlays, banner injection, and ad-slot rewriting.
• H061 Detects clickjacking via transparent overlays on top of ad units.
• H062 Detects hidden iframe networks loading ad chains in the background.
• H063 Detects auto-play media abuse used to force impression and viewability counts.
• H064 Detects scripted scroll behavior used to fake viewability thresholds.
• H065 Detects scripted focus and blur events used to bypass active-tab requirements.
• H066 Detects scripted pointer events synthesized to fake user gestures.
• H067 Detects scripted touch events synthesized on desktop browsers.
• H068 Detects mouse movement curves that are too linear or too uniform to be human.
• H069 Detects keyboard input with impossible inter-key timing for a human typist.
• H070 Detects rapid form-fill behavior at machine speed across many fields.
• H071 Detects identical session shapes repeated across many fingerprints.
• H072 Detects visit durations clustered at exact intervals indicating scripted browsing.
• H073 Detects identical scroll depth and timing repeated across sessions.
• H074 Detects mouse paths that match recorded macro replays.
• H075 Detects impression bursts that exceed normal page-load rates.
• H076 Detects ad-request flooding from a single fingerprint or IP.
• H077 Detects bid-request duplication and replay across exchanges.
• H078 Detects ad-server response replay used to inflate impression counts.
• H079 Detects fingerprint reuse across mutually exclusive geographies.
• H080 Detects sessions with impossible navigation timing values.
• H081 Detects sessions whose total resource transfer is too small for the claimed page.
• H082 Detects suspicious in-page network activity targeting non-publisher hosts.
• H083 Detects ad-call patterns that match known malvertising infrastructure.
• H084 Detects creative responses that load secondary tags from unauthorized exchanges.
• H085 Detects creatives that auto-redirect the top frame to a different domain.
• H086 Detects creatives that drop tracking cookies for unrelated third parties.
• H087 Detects forced full-screen takeovers on first interaction.
• H088 Detects creatives that initiate file downloads without user consent.
• H089 Detects creatives that request elevated browser permissions.
• H090 Detects creatives attempting cryptocurrency wallet interactions.
• H091 Detects creatives that abuse the Notification API to drive subscription fraud.
• H092 Detects time-of-day session anomalies inconsistent with the claimed geo.
• H093 Detects JavaScript-level timestamp manipulation via patched Date or performance APIs.
• H094 Detects ad request bursts at physically impossible loading rates.
• H095 Detects setInterval-driven automation firing events at exact timer intervals.
• H096 Detects mobile SDK spoofing where a WebView masquerades as a native app.
• H097 Detects ad tag tampering such as publisher ID swaps and floor-price manipulation.
• H098 Detects fabricated signal payloads with internally contradictory or all-zero fields.
• H099 Detects replayed signal payloads via hash deduplication and stale timestamps.
• H100 Detects forged cryptographic signatures on bid requests and impression tokens.
• H101 Detects known bot UA signatures and verifies legitimacy via reverse DNS.
• H102 Detects IPs on fraud, abuse, or reputation blocklists.
• H103 Detects ASNs flagged as bulletproof hosting or known fraud infrastructure.
• H104 Detects device fingerprints previously seen running anti-detect templates.
• H105 Detects shared or copied fingerprints used across many countries simultaneously.
• H106 Detects hypervisor GPU strings from VirtualBox, VMware, Parallels, QEMU, or VirtIO.
• H107 Detects Docker or Kubernetes containerized browsers via minimal resource profiles.
• H108 Detects RDP and VNC sessions via locked low-FPS with near-zero variance.
• H109 Detects sandboxed iframe contexts and test-framework globals like Karma or Jest.
• H110 Detects docked DevTools via a 300px-plus viewport gap.
• H111 Detects code injected directly through the browser console.
• H112 Detects Web Worker abuse via abnormal worker counts and SharedArrayBuffer coordination.
• H113 Detects hijacked service workers intercepting or replaying ad requests.
• H114 Detects WebSocket connections to known C2 or fraud domains.
• H115 Detects in-browser crypto mining via WASM modules and mining-pool connections.
• H116 Detects pre-loaded DMP audience cookies present without their data-provider scripts ever running.
• H117 Detects the same audience cookie value reused across many distinct IPs.
• H118 Detects cookies farmed in one browser engine and imported into another.
• H119 Detects retargeting cookies that lack the supporting first-party history a real user would have.
• H120 Detects sessions where the snippet ran cleanly but recorded zero human interaction alongside corroborating signals.
• H121 Detects one stable browser fingerprint observed from many distinct IPs over 24 hours.

The Modules indicating Medium Fraud

• M001 Detects suspicious referrer sources such as known traffic brokers, high-risk TLDs, newly registered domains, NXDOMAIN, and HTTP-to-HTTPS downgrades.
• M002 Detects physically impossible viewports, sub-100px hidden impression frames, and mobile UAs running at desktop widths.
• M003 Detects impression harvesting via zero-interaction sessions, sub-2s impression-and-exit, and immediate exit after impression fire.
• M004 Detects implausible session durations including 4-hour single-page dwell and 5+ impressions fired in under one second.
• M005 Detects background tab abuse where impressions fire on tabs that never become visible.
• M006 Detects fingerprint drift across a session, mid-session hash changes, and platform or browser-family changes between visits.
• M007 Detects stale or transplanted session tokens including cookies present with a completely different fingerprint than last seen.
• M008 Detects traffic-laundering navigation through excessive redirect chains, multi-domain hopping, and hidden iframe relays.
• M009 Detects elevated bid-request, fetch, and XHR rates inconsistent with normal user activity.
• M010 Detects JavaScript error anomalies from injection artefacts, failed ad requests, and unknown-origin console errors.
• M011 Detects Battery API tampering such as patched getBattery, impossible values outside 0 to 1, and battery readings on desktop UAs that would not have one.
• M012 Detects plugin anomalies including patched navigator.plugins, anti-detect template plugin sets, and missing PDF viewer on Firefox.
• M013 Detects font enumeration fingerprinting via canvas.measureText volume and transient DOM measurement elements.
• M014 Detects AudioContext fingerprint manipulation through oscillator hash mismatches and known anti-detect audio templates.
• M015 Detects canvas output randomization where render-to-render variation, blank canvases, or shared hashes across many hardware profiles betray anti-detect tooling.
• M016 Detects IPs serving unusually many distinct sessions or fingerprints, indicating shared proxies or bot-farm exit nodes.
• M017 Detects impossible geographic shifts between sessions given the elapsed time, and multi-country fingerprint cycling.
• M018 Detects HTTP header and navigator property inconsistencies such as Accept-Language vs navigator.language or Client Hints brand mismatch.
• M019 Detects TLS-layer anomalies including JA3 hash mismatch with the declared browser and non-standard cipher ordering.
• M020 Detects suspicious cookie-disabled sessions with corroboration, excluding privacy browsers where this is expected.
• M021 Detects made-for-advertising page layouts where ad containers load before or instead of real content.
• M022 Detects JavaScript that auto-accepts the consent banner with no real user interaction, fabricating GDPR consent signals.
• M023 Detects artificial bid-price inflation via injected audience segments, manipulated Prebid floors, and DMP enrichment scripts on thin-content pages.
• M024 Detects publishers serving adult or explicit content while declaring brand-safe inventory to advertisers.

The Modules indicating low Fraud

• L001 Detects outdated browser versions, from end-of-life Internet Explorer down to old Chrome, Firefox, and Safari builds.
• L002 Detects deprecated operating systems, separating impossible pre-modern OSes from merely legacy ones like XP, Vista, or old Android.
• L003 Detects screen resolutions outside any real device range, including sub-240px frames, beyond-16K resolutions, and impossible aspect ratios.
• L004 Detects missing or anomalous HTTP request headers such as absent Accept, missing Sec-Fetch on modern Chrome, and Host mismatches.
• L005 Detects severely restricted JavaScript environments where scripts are blocked or no event listeners exist despite scripts loading.
• L006 Detects contradictory Network Information API values like WiFi reporting 2G speeds or zero RTT on an active connection.
• L007 Detects impossibly high or fabricated latency values, including RTT exceeding physical Earth-routing limits.
• L008 Detects incomplete signal payloads by counting required fields missing from the probe response.
• L009 Detects contradictory first-visit claims where the browser claims to be brand new but the storage state says otherwise.
• L010 Detects sessions at unusual local hours such as 2 to 4 AM, especially when combined with timezone or IP mismatch.
• L011 Detects single-page sessions with anomalous engagement such as multiple impressions firing with no interaction.
• L012 Detects sessions with zero interaction across all input channels after a meaningful dwell window has passed.
• L013 Detects sessions with minimal but nonzero interaction like a single click without any cursor movement.
• L014 Detects font lists inconsistent with the declared OS, including Windows UAs missing Windows fonts or fingerprints matching anti-detect templates.
• L015 Detects low-entropy fingerprints such as stripped UAs, hashes with low Shannon entropy, and many zero-valued dimensions indicating low-effort fabrication.

1. Each detector is independent and self-scoring

Every detector module reads the merged signal record and returns at most one Result. A Result has:

• a confidence value between 0 and 1
• a flagged flag (true if confidence crosses that detector's own threshold, typically 0.55 to 0.70)
• a risk level (High, Medium, Low, or MFA)
• a filtration type (GIVT for trivial bots, SIVT for sophisticated invalid traffic)

Inside a detector the confidence is built additively from its own evidence. A typical detector starts at a low base (around 0.20 to 0.30) and adds smaller amounts (0.10 to 0.40) for each corroborating signal it finds. Detectors only flag when the page-context, fingerprint, and network signals all agree, so a single weak hit cannot push them over the line.

2. All detectors run in parallel against the merged signals

The engine dispatches every enabled detector concurrently against the same hydrated signal record. That record already includes:

• the client-side probe data
• the late supplemental beacons (auction, NSFW) merged on sessionId
• server-side IP and ASN enrichment from MaxMind
• precomputed aggregates from ClickHouse (fingerprint to IP fanout, cookie collision counts, first-seen age, etc.)

Detectors never see each other, do not chain, and cannot disable one another. The result list is just the union of everything that flagged.

3. Risk levels weight each flagged result

When the dispatcher gathers the results, each flagged finding contributes:

result_score = confidence * risk_weight(level)

where the weights are:

• High → 3.0
• Medium → 1.5
• Low → 0.5
• MFA → 0 (informational only, never moves the score)

So a High-risk detector flagging at 0.80 confidence contributes 2.4 to the session score, while a Low detector at the same confidence contributes 0.4.

4. Per-session score and verdict

The contributions add up across every flagged detector to produce a single totalScore for the session, and the verdict is bucketed:

• totalScore > 12 → INVALID
• 5 to 12 → SUSPICIOUS
• 1.5 to 5 → LOW_RISK
• ≤ 1.5 → CLEAN

So one strong High at full confidence (3.0) already lands a session in LOW_RISK, two co-firing Highs push it into SUSPICIOUS, and four or more, or one or two Highs co-firing with a stack of corroborating Mediums and Lows, push it into INVALID.

5. GIVT vs SIVT bookkeeping

Every detector also declares a filtration type. The dispatcher counts how many flagged results were GIVT (general invalid traffic such as known crawlers, datacenter IPs, headless browsers) versus SIVT (sophisticated invalid traffic such as click farms, cookie injection, retargeting seed harvesting, fingerprint fanout). The verdict above is the headline number, but the GIVT vs SIVT counts are what the dashboard uses to label the traffic on the Quality Report, so a publisher can distinguish unsophisticated bot noise from real fraud operations.

I run an ad tech company that operates exclusively in the firearms, hunting, sporting goods, and outdoor space. Meta, Google, TikTok and most mainstream programmatic supply excludes it and I'm curious if others manage similarly restricted vertical supplies?

We are at about 1B monthly impressions across display, video, and CTV at this point, currently handling all monetization internally outside of a few demand partners, and looking to add more. Happy to chat with anyone on the demand side who's interested. Mostly curious about the broader discussion though, especially from folks running supply in similar structurally-excluded categories.

The Setup works by setting up multiple Proxy Antidetect Browsers and visiting specific RTBHouse or Criteo Tracking Links. This injects the Tracking Pixel and fakes interest in specific High paying Ads.

I don't know who else to tell this, seems like none of the IVT Solutions detect this. It also seems like none of the Advertisers really care.

I can share Insights with People from these Companies and I can also share a Way to detect that specific Thing.

Hi everyone,

I recently applied to Mediavine Journey (about 10 days ago) and my application is currently under review. While I wait, I’d love to hear from anyone already using the platform, specifically regarding what kind of RPMs I might expect with my current metrics.

To give you some context, here is a snapshot of my last 30 days (growing steadily):

• Sessions: 13.8K
• Page Views: 57.9K
• Avg. Session Duration: 5m 49s

My traffic is mostly European-based, with Spain, Italy, UK, and France being my top 4 countries. I also have a growing audience in the US (currently around 5th place in traffic volume).

For those already in Journey:

1. How long did the "Under Review" process take for you?
2. Given my high engagement (long sessions/low bounce) but mostly European traffic, what RPM range should I realistically anticipate?

Thanks in advance for any insights.

Hi everyone, I need some advice.

I am the owner of an educational history website for students, teachers and enthusiasts (Italian traffic). I built the website completely from scratch (custom code, no WordPress). It is very fast and currently gets about 18,000/20,000 pageviews per month, all from seo.

My problem: I have applied to Google AdSense many times, but I always get rejected automatically for "Low Value Content". I think the bot gets confused because it's a custom-coded site with long academic text, so it's a false positive.

I am now looking into Google Certified Publishing Partners. My questions are:

1. If I partner with an GCPP network, will I have a better chance of getting approved to serve Google ads (Ad Exchange)?
2. How does the GCPP approval process work? Will a real human at Google finally review my site instead of the basic AdSense bot?
3. Do GCPP partners actively help you fix issues to make sure you pass the Google review?

Any advice is welcome. Thanks!

My recipe niche site just hit 10k monthly sessions, mostly US and tier 1 traffic coming primarily from Pinterest. Adsterra has been terrible, sketchy and low quality ads. Got rejected by Mediavine too. Currently waiting on Monumetric review but open to other suggestions. What are you guys using at this traffic level that is actually worth it?

I scan ads.txt, sellers.json, and schain across hundreds of thousands of domains. Errors everywhere. Wrong DIRECT/RESELLER, dead SSPs still listed, missing schain, sellerID mismatches.

Pulled this from one of the top sites this morning. 84% of bids ship without a supply chain. On a Tier 1 publisher.

I sometimes see a 30% bid CPM difference between requests with a clean schain and ones without. And still nobody seems to care.

Who here actually cares about SPO? Or is everyone just talking about transparency without acting on it?

https://preview.redd.it/560rmw62o81h1.png?width=734&format=png&auto=webp&s=bd9de763269e0652bfd421e9d0923bfce091af7f

Hey everyone,

I just wanted to share a quick update for those looking to join Mediavine. It seems they’ve shifted their entry requirements. While we used to focus purely on reaching a specific monthly session count (like 50k), the focus has now shifted toward proven revenue.

According to their latest update, to apply for the main Mediavine platform, your site now needs to generate at least $5,000+ in annual ad revenue. This change ensures that a site is truly ready for their premium demand.

For those of us who aren't at that $5k mark yet, they are directing people toward Journey by Mediavine, which acts as their "on-ramp" for growing sites and starts at 1k sessions.

Has anyone else noticed this shift affecting their application process? It definitely changes the roadmap for newer publishers!

Been noticing a shift recently on larger publisher/media WordPress setups.

A lot of workflows that used to be manual are slowly getting AI-assisted now:

• metadata generation
• content optimization
• internal linking
• editorial prep
• SEO monitoring

But interestingly, it also seems to create a different kind of operational overhead:

• quality control becomes harder
• editorial review standards shift
• indexing problems scale faster
• content velocity increases faster than governance/processes

Feels like publisher WordPress stacks are changing much faster than normal marketing/business sites right now.

For people working in publishing/adops/media environments:

Are you seeing AI meaningfully change workflows already, or is most of it still experimental internally?

Last 28 days traffic graph

Traffic shares (Country wide)

Okay so this is the stats of my website. Growing traffic since we are doing major updates in the website. At this point we've crossed 900 active users daily. I believe the traffic will continue to grow and I would like to monetize it. Never tried any adsense alternative so which could be the best platform? I don't have enough patience to wait 3 months for approval. Your 2 cents would be very helpful.