====================================================================
FreeJobAlert.com — 300x250 Ad Unit Analysis & Suggestions
Date: 2026-05-27
Ad Unit: /40776336/FJA_Jobs_siteWide_top_300*250 (ID: 23311301143)
Period Analyzed: Apr 27 – May 26, 2026
====================================================================


1. CURRENT PERFORMANCE
====================================================================

Monthly Impressions:     6,968,826
Monthly Revenue:         $1,298.12
CPM:                     $0.186 (lowest of any active unit)
Viewability:             47.2% (below 50% industry threshold)
Viewable CPM:            $0.39
CTR:                     0.49%
Daily Revenue:           ~$43/day

By Device:
  Desktop      3,750,209 imps (53.8%)   $770.68   CPM $0.21   Viewability 50.2%
  Smartphone   3,200,908 imps (45.9%)   $525.50   CPM $0.16   Viewability 43.7%
  Tablet          17,452 imps (0.3%)      $1.89   CPM $0.11   Viewability 47.0%

By Country (Top 5):
  India                  6,924,011 imps   $1,279.14   CPM $0.18
  United States              4,372 imps       $4.18   CPM $0.96
  United Arab Emirates      11,004 imps       $4.08   CPM $0.37
  United Kingdom             3,647 imps       $3.67   CPM $1.01
  Canada                     2,563 imps       $2.58   CPM $1.01


2. KEY FINDING: ONLY 20% OF PAGE VIEWS LOAD ANY ADS
====================================================================

The 300x250 HTML div and GPT JavaScript code are present on ALL page
types (homepage, category, article pages). The div is NOT missing from
any live page.

However, only 20.1% of total page views actually trigger an ad request:

  Total monthly page views:        34,591,089
  300x250 monthly impressions:      6,968,826
  Effective ad-load rate:               20.1%

Ad-load trigger rate by page type (estimated from AdSense data):

  Page Type           Views        AdSense Imps/PV   Est. Trigger Rate
  -----------------------------------------------------------------------
  Homepage            7,348,883    0.20              ~20%
  Category/other     11,497,036    0.19              ~19%
  /articles/ pages   15,745,170    1.52              ~76%

Article pages work because users scroll to read content, triggering
event listeners quickly. Homepage/category users click links and leave
before ads ever load.


3. ROOT CAUSE: TWO-LAYER DEFERRAL CHAIN
====================================================================

The site uses TWO layers of script deferral that stack on top of each
other, creating a 5-6 second delay before any ad loads:

LAYER 1 — Cloudflare Rocket Loader:
  All inline <script> tags are rewritten by Rocket Loader from
  type="text/javascript" to type="[hash]-text/javascript". This
  prevents immediate execution. Rocket Loader executes them
  asynchronously after the page is interactive (~1-3 seconds).

LAYER 2 — Deferred ad loading pattern (your inline JS):
  Once Rocket Loader runs the script, your code registers event
  listeners (keydown, pointerdown, mousemove, touchstart, scroll)
  and sets a setTimeout of 3,000ms as fallback.

Combined timeline from user's perspective:

  0s       Page HTML loads, user sees content
  ~1-2s    Cloudflare Rocket Loader starts executing deferred scripts
  ~2-3s    Your inline script runs, event listeners registered,
           setTimeout(3000) countdown starts
  ~5-6s    If NO user interaction by now → setTimeout fires →
           GPT + AdSense load → ad request → ad renders

On homepage/category pages, users scan and click a job link within
2-4 seconds. By the time the 3-second fallback fires (actually 5-6s
from page load), the user has already navigated away.

This is why:
  - Homepage:  80% of views load ZERO ads
  - Category:  81% of views load ZERO ads
  - Articles:  24% of views load ZERO ads (users scroll/touch early)


4. VIEWABILITY PROBLEM (47.2%)
====================================================================

Even when the ad DOES load, it is viewable less than half the time.

Why desktop is 50.2% (borderline acceptable):
  - The 300x250 sits between header/navigation and main content
  - Desktop screens are wide enough that the ad is in the natural
    viewport area
  - Users tend to see it before scrolling

Why smartphone is only 43.7% (below threshold):
  - On a ~360px screen, the 300x250 occupies 83% of screen width
  - Position is above content — users thumb-scroll past it immediately
  - Deferred loading means the ad renders AFTER the user has already
    scrolled past the slot position
  - Most premium buyers set 50%+ viewability floors, so this unit is
    excluded from their campaigns → lower CPM

Daily viewability is flat (45.7% to 49.3% range) — this is a
structural/positional problem, not a traffic-pattern issue.


5. AD POSITION ON EACH PAGE TYPE
====================================================================

Homepage:
  After the first navigation section (quick links grid), before the
  main job category sections. Wrapped in:
  <div style="text-align: center; margin: 10px auto;">

Category pages (e.g. /government-jobs/):
  After the "WWW.FREEJOBALERT.COM" header link, before the first job
  category table (e.g. UPSC table). Top of content area.

Article pages (e.g. /articles/rrb-alp-...):
  Inside the <header> block, directly below the <h1> title tag:
    <h1>Article Title...</h1>
    <div style="text-align: center; margin: 10px auto;">
        <div id='div-gpt-ad-1753936579483-0'
             style='min-width: 300px; min-height: 250px;'></div>
    </div>
    <div class="entry-meta">...</div>


6. SUGGESTED CHANGES (PRIORITY ORDER)
====================================================================

----------------------------------------------------------------------
CHANGE 1 — Fix Rocket Loader delay for ad scripts
Priority: HIGHEST
Effort: Low
Impact: +$450-550/month from 300x250 alone, plus boost to ALL other
        ad sources (AdSense, Auto-Ads, VDO.AI, GAM page-level formats)
----------------------------------------------------------------------

The biggest problem is Cloudflare Rocket Loader adding 1-3 seconds of
delay BEFORE your deferred loading script even starts.

Option A (Recommended): Exclude the ad-loading inline script from
Rocket Loader by adding the data-cfasync="false" attribute:

  CURRENT:
  <script type="text/javascript">
    ;let userInteracted=!1;let scriptsAdded=!1;...
  </script>

  CHANGE TO:
  <script data-cfasync="false" type="text/javascript">
    ;let userInteracted=!1;let scriptsAdded=!1;...
  </script>

This tells Cloudflare Rocket Loader to NOT defer this specific script.
The event listeners will register immediately on page load. The
setTimeout(3000) will actually fire at 3 seconds, not 5-6 seconds.

Where to make this change:
  - This inline script appears at the bottom of every page template
    (homepage, category pages, article pages)
  - It is inside the last <script> tag before </body>
  - The script contains the addScripts(), addEmbeds(), and
    triggerScriptsOnce()/userInteracted functions

Option B (Alternative): Disable Rocket Loader entirely in Cloudflare.
  Cloudflare Dashboard → Speed → Optimization → Rocket Loader → OFF

  This is a blunter approach. Your ad scripts already use their own
  deferred loading pattern, so Rocket Loader is adding a redundant
  second layer of deferral that hurts ad revenue. However, disabling
  Rocket Loader affects ALL scripts on the site, not just ads.

Expected result: Homepage/category ad-load trigger rate should improve
from ~20% to ~50-60%, since more sessions will last the full 3 seconds
from actual page load (not 5-6 seconds).


----------------------------------------------------------------------
CHANGE 2 — Reduce the fallback setTimeout from 3000ms to 1500ms
Priority: HIGH
Effort: Very low (change one number)
Impact: +$100-200/month additional
----------------------------------------------------------------------

In the inline ad-loading script, the fallback timer is set to 3000ms:

  CURRENT:
  setTimeout(()=>{if(!userInteracted){addScripts();addEmbeds()}},3000);

  CHANGE TO:
  setTimeout(()=>{if(!userInteracted){addScripts();addEmbeds()}},1500);

With Change 1 applied (Rocket Loader fix), the actual wall-clock time
would be 1.5 seconds from page load instead of 3 seconds. This catches
more homepage/category users who click links within 2-3 seconds.

Tradeoff: Slightly earlier loading of ad scripts (gpt.js, adsbygoogle.js,
vdo.ai.js). These are lightweight async scripts — minimal impact on
page performance.

Where to make this change:
  - Same inline script at the bottom of every page template
  - Search for "3000" in the script — it appears once, in the setTimeout


----------------------------------------------------------------------
CHANGE 3 — Enable GPT Lazy Loading for the 300x250
Priority: MEDIUM
Effort: Low (add 1 line of JavaScript)
Impact: +$100-150/month (viewability improvement → higher CPM)
----------------------------------------------------------------------

GPT supports lazy loading, which delays the ad request until the slot
is near the viewport. This ensures the ad renders only when the user
is about to see it → higher viewability → higher CPM.

Add this line inside the GPT configuration block, before enableServices():

  CURRENT:
  googletag.cmd.push(function(){
    googletag.defineSlot('/40776336/FJA_Jobs_siteWide_top_300*250',
      [300,250],'div-gpt-ad-1753936579483-0')
      .addService(googletag.pubads());
    googletag.pubads().enableSingleRequest();
    googletag.enableServices()
  });

  CHANGE TO:
  googletag.cmd.push(function(){
    googletag.defineSlot('/40776336/FJA_Jobs_siteWide_top_300*250',
      [300,250],'div-gpt-ad-1753936579483-0')
      .addService(googletag.pubads());
    googletag.pubads().enableSingleRequest();
    googletag.pubads().enableLazyLoad({
      fetchMarginPercent: 200,
      renderMarginPercent: 100,
      mobileScaling: 2.0
    });
    googletag.enableServices()
  });

What this does:
  - fetchMarginPercent: 200 = start fetching the ad when the slot is
    within 200% of viewport height (2 screens away)
  - renderMarginPercent: 100 = render the ad when the slot is within
    100% of viewport height (1 screen away)
  - mobileScaling: 2.0 = multiply these margins by 2x on mobile
    (larger fetch window on mobile to account for fast scrolling)

This is especially helpful on mobile where the 300x250 sits above the
content. Without lazy load, the ad request fires immediately (before
the user scrolls to it). With lazy load, the ad fires when the user is
actually near the slot → the ad is fresh and in-view → higher
viewability.

Where to make this change:
  - Same inline script at the bottom of every page template
  - Inside the googletag.cmd.push block


----------------------------------------------------------------------
CHANGE 4 — Use multi-size slot for mobile
Priority: MEDIUM
Effort: Medium (requires GAM line item setup + code change)
Impact: +$50-100/month (more mobile demand sources)
----------------------------------------------------------------------

Currently the slot only accepts 300x250. On mobile (46% of 300x250
impressions), smaller formats may get better viewability and access
more mobile-specific demand.

  CURRENT:
  googletag.defineSlot('/40776336/FJA_Jobs_siteWide_top_300*250',
    [300,250],'div-gpt-ad-1753936579483-0')

  CHANGE TO:
  googletag.defineSlot('/40776336/FJA_Jobs_siteWide_top_300*250',
    [[300,250],[336,280],[320,100]],
    'div-gpt-ad-1753936579483-0')
    .defineSizeMapping(
      googletag.sizeMapping()
        .addSize([768, 0], [[300,250],[336,280]])
        .addSize([0, 0], [[300,250],[336,280],[320,100]])
        .build()
    )

This serves:
  - Desktop (768px+): 300x250 or 336x280
  - Mobile (<768px): 300x250, 336x280, or 320x100

The 320x100 mobile banner is a smaller format that takes less screen
space → users are more likely to see it → higher viewability. However,
it typically has a lower CPM than 300x250, so the net effect depends on
whether the viewability gain outweighs the format CPM difference.

NOTE: Before making this change, ensure that your GAM line items and
Ad Exchange rules are configured to serve into these additional sizes.

Also update the div's min-height for mobile to avoid CLS:
  Current: style='min-width: 300px; min-height: 250px;'
  For multi-size, consider removing min-height or making it responsive.


----------------------------------------------------------------------
CHANGE 5 — Split the ad unit by page type in Google Ad Manager
Priority: LOW (analytics/optimization, not immediate revenue)
Effort: Medium (GAM configuration + code changes)
Impact: Better data, ability to set per-page-type floor prices
----------------------------------------------------------------------

Currently one ad unit (FJA_Jobs_siteWide_top_300*250) serves across
all page types. This makes it impossible to:
  - Know how the 300x250 performs on homepage vs articles vs category
  - Set different floor prices (articles may support higher floors)
  - Apply different targeting rules per page type

Suggested setup in GAM:
  1. Create new ad units:
     - FJA_Homepage_top_300x250
     - FJA_Article_top_300x250
     - FJA_Category_top_300x250
  2. Update the defineSlot() call on each page template to use the
     corresponding unit name
  3. Keep the same div ID to minimize HTML changes
  4. Copy existing line items/targeting to the new units

This is not urgent but gives you the data to optimize each placement
independently over time.


7. IMPACT SUMMARY
====================================================================

Change                                   Effort     Est. Monthly Impact
----------------------------------------------------------------------
1. Fix Rocket Loader delay               Low        +$450-550 (300x250)
   (data-cfasync="false")                           + boost to ALL ads
                                                     on homepage/category

2. Reduce setTimeout to 1500ms           Very Low   +$100-200

3. Enable GPT lazy loading               Low        +$100-150
   (enableLazyLoad)

4. Multi-size mobile slot                Medium     +$50-100

5. Split ad unit by page type            Medium     Better analytics
----------------------------------------------------------------------
TOTAL ESTIMATED FROM 300x250 ALONE:                 +$700-1,000/month

IMPORTANT: Change 1 (Rocket Loader fix) affects ALL ad loading, not
just the 300x250. The same 80% of homepage/category page views that
miss the 300x250 also miss:
  - AdSense manual slots and Auto-Ads
  - VDO.AI video ads
  - GAM page-level formats (FL_Rewarded_Ad, FJ_web_inter, sticky ads)

The total revenue impact of fixing the Rocket Loader delay across ALL
ad sources on homepage/category pages could be significantly higher
than the 300x250-only estimate above.


8. ADDITIONAL CONTEXT
====================================================================

Comparison with other AdX units (for reference):

  Ad Unit                         Imps       Revenue    CPM     View%
  -------------------------------------------------------------------
  FL_Rewarded_Ad (Web Rewarded)   4,673,506  $4,791.66  $1.03   61.5%
  FJ_web_inter (Web Interstitial) 2,214,922  $1,705.93  $0.77   —
  FJA_Article_Top_sticky          2,983,790  $1,589.83  $0.53   —
  FJA_Jobs_siteWide_top_300*250   6,968,826  $1,298.12  $0.19   47.2%
  FJA_Site_wide_BottomSticky      2,980,015  $1,036.39  $0.35   —

The 300x250 has the HIGHEST impressions but LOWEST CPM and LOWEST
revenue per impression of any major unit. The primary reason is the
47.2% viewability excluding it from premium demand.

Daily revenue trend is flat (~$43/day, range $28-$55). No anomalies
or trends. Weekday ($43.73/day avg) and weekend ($42.02/day avg) are
nearly identical.

Geo: 99.4% of impressions from India ($0.18 CPM). US/UK/Canada show
$0.96-$1.01 CPM — 5x higher — but represent <0.1% of volume.
====================================================================
END OF REPORT
====================================================================