CodeCanyon Progress Ads - WordPress Plugin

How wait-based ads with a skip button work

Progress Ads mimics a familiar pattern from video services and mobile apps: before the visitor can access the main content, a window appears where you can display an ad block, video, shortcode, form, or custom HTML. The visitor sees a progress or wait indicator and, after the configured interval, gets the option to close the screen and continue viewing the page.

This logic is different from a standard banner. A banner lives inside the page and does not block reading, while a skippable window temporarily captures the visitor's attention. That makes it more noticeable, but also much more sensitive to mistakes. Showing it too early, setting the wait too long, using unsuitable AdSense code, or having poor mobile layout can hurt user behavior and create risk for your ad network.

What the product page confirms

Based on the available CodeCanyon description, the plugin supports several key mechanisms:

• A progress bar with color, height, and style settings.
• A modal window for ad content, forms, custom code, video, and shortcodes.
• A wait time before the skip button becomes available.
• Frequency limits so the same visitor does not see the window too often.
• A display trigger based on either a timer or scroll position.
• Post type selection for where the ad screen should run.
• An option to disable display for users who are already logged in.
• Mobile settings and appearance controls for the modal window.

These features are fairly focused, and that is exactly the point of the product. It is not a full ad campaign manager, it does not provide advanced analytics, and it does not sell ad placements. Its job is to show a prominent ad or promo screen before the content and give the visitor a clear path forward.

What not to expect from the plugin

You should not treat the promise of compatibility with themes and plugins as an absolute guarantee. The product page lists supported WordPress versions and compatible solutions, but every real site build is different in terms of theme, caching, minification, cookie banners, chat widgets, and ad scripts. That is why every configuration should be tested on a staging copy of the site, or at least on a separate test page.

It is also important to remember that the product page states that author support is not included for this item. That does not mean you cannot use it, but it does change the way you should approach it: you need a rollback plan in advance, you should not rely on a quick response from the developer, and you should not make this plugin a critical part of your site's navigation flow.

Where this format works well and where it quickly becomes disruptive

Skippable ads work best where the visitor already understands the value of the page and is willing to tolerate a short pause. That might be a long tutorial, an archive of resources, a page with a free file, a catalog with extra content, or an informational article where the visitor is not trying to complete something urgent. But if someone is checking out, posting a comment, recovering a password, or going into their account area, a modal window will almost always be unnecessary friction.

The plugin supports post type targeting, so the strategy should not be built around the idea of "show it to everyone." It should be built around the question "on which page types will this ad screen not break the visitor's intent?" In WordPress, that matters because post types can include standard posts, pages, WooCommerce products, bbPress forum topics, Easy Digital Downloads content, and content created by other extensions.

Good use cases

It is best to start with content where the visitor is already in reading or learning mode. On those pages, a gentle display after a short delay or after some scrolling feels much less intrusive than an instant full-screen overlay on first load.

• Long articles, reviews, roundups, and tutorials where there is a natural pause before the visitor continues reading.
• Pages with free content where an ad block can be shown before access to the main material.
• Areas driven by non-logged-in traffic, if regular users do not need to see the ads.
• Specific post types where the site owner is willing to test the ad format without risking orders or lead submissions.

Higher-risk areas

Some parts of the site are better excluded from the start. A wait-and-skip format may be noticeable, but it should not interfere with payments, registration, support access, or any other high-value action.

If the site gets a lot of mobile search traffic, be especially careful. Google Search Central explicitly warns that intrusive dialogs and full-screen interstitials can make it harder for both users and search engines to understand the content. For an ad window, that leads to a simple rule: the smaller the screen and the earlier the window appears, the less aggressive the experience should be.

What to check before installation

Before you install Progress Ads, prepare more than just the ZIP archive. You also need a test setup. This plugin creates a public-facing visual effect, so any mistake is immediately visible: the page may get covered, the skip button may land off-screen, the ad code may fail to load, or the display frequency may annoy returning visitors.

The first step is to define one test area. For example, only blog posts in one category, or one private test page. The second step is to list the pages where the window must never appear: cart, checkout, account pages, the login page, the privacy policy, contact pages, system URLs, and any pages tied to private communication.

Compatibility and project state

The CodeCanyon listing shows compatibility up to a certain WordPress branch and also claims integrations with WooCommerce, Elementor, Elementor Pro, Easy Digital Downloads, bbPress, and WPML. That is a useful starting point, but it is not a final compatibility check. If your site runs a newer version of WordPress or relies heavily on JavaScript optimization, testing on a staging copy becomes mandatory.

• Check which WordPress version the site is using and whether it falls within the range listed on the product page.
• Review whether page caching, delayed JavaScript loading, file combination, and CDN optimization are enabled.
• Make a list of elements that already use modal windows: the cookie banner, chat, signup form, age gate, or floating cart.
• Decide which ad networks or custom banners will be displayed inside the window.
• If you plan to use AdSense, review placement policies in advance, because pre-roll and pop-up scenarios come with separate Google restrictions.

Minimum rollback plan

Your rollback path should be simple. Before enabling the plugin, note where the disable setting is located, which post types were enabled, and which parameters were changed. If the site uses caching, make sure in advance that you can clear the plugin cache, CDN cache, and browser cache. That will save time if the ad window gets stuck on top of the page or keeps appearing after you disable it.

Do not start with the home page or checkout. For the first rollout, one page is enough to safely test the display, wait timer, skip button, repeat visit, and mobile version.

Installation and first launch without aggressive display

Commercial CodeCanyon plugins are usually installed by uploading a ZIP archive in the WordPress admin panel. The standard flow is straightforward: open Plugins, go to Add New, choose Upload Plugin, upload the archive, click Install Now, and then activate the plugin with Activate Plugin. If the archive includes both the plugin and documentation, make sure you upload the installable plugin ZIP rather than the full package.

After activation, do not immediately enable the display for all post types. First, find the Progress Ads settings area in the admin panel, review the toggle states, and disable any unnecessary zones. If the interface includes a global enable/disable switch, leave global display off until you have configured the window content and display frequency.

Initial post-activation check

1. Open the plugin settings page and make sure the ad window is not enabled globally without your explicit decision.
2. Create test content for the window: a short custom HTML block, a simple image, or a safe shortcode that you already know works outside the modal.
3. Select one post type or one test page, if the interface allows you to limit the display.
4. Set a short wait time so you can test the mechanics without annoying users.
5. Open the page in incognito mode and make sure the window appears only in the selected scenario.
6. Repeat the visit after closing the window and check whether the frequency limit works.

How not to confuse a plugin issue with cache

If you changed a setting but nothing changed on the front end, that does not automatically mean Progress Ads is broken. The page may be coming from cache, and scripts may be combined or delayed until the visitor interacts with the page. Check the page with caching disabled, clear the site cache, and open the result in another browser. If the change is visible only to the administrator but not to a regular visitor, look at cache and display conditions first.

Basic configuration after activation

Detailed Progress Ads setup comes down to four questions: when to show the window, how long to wait before allowing a skip, who should see it, and how often it should repeat. Appearance matters, but behavior comes first. A beautiful window that appears too often or covers an important button is still a bad implementation.

Wait time and skip button

Ad Waiting Time controls how long the visitor must wait before accessing the content. If the interval is too short, the format becomes little more than a standard pop-up. If it is too long, it turns into a barrier. For the first test, choose the shortest interval that still makes sense and watch bounce behavior, engagement depth, and user complaints.

If the window contains a video or form, do not tie the wait period to full completion. The visitor should understand what is happening, see the progress state, and have a predictable way to close the window. The skip button must be visible on both desktop and mobile and should not be covered by a cookie banner, bottom navigation, or a chat widget.

Display frequency

Ad Display Frequency protects the site from the most common mistake: showing the window on every page. The product page gives an example where, after seeing the modal once, the visitor does not see it again for a while. In real-world setup, this is one of the most important parameters. If the interval is too short, the visitor will experience the ad screen as a penalty for navigating the site.

For a typical informational site, it makes sense to start with infrequent display: once per session, or with a clear gap between repeats if that logic is available in your version. After testing, you can adjust the frequency, but not the other way around. First protect the user experience, then look for a monetization balance.

Progress bar and window styles

Progress Ads lets you change the progress bar color, style, and height, along with the modal background, ad area, button color, and text. Visually, that should match the site's theme, but it should not disguise the ad as a system message or navigation element. If the window contains an ad block, label it honestly, for example "Ad" or "Promo."

Do not make the close button look too much like part of the ad itself. The visitor should be able to tell where the ad is, where the continue action is, and where the site's main content begins. That reduces accidental clicks and makes the window's behavior more transparent.

Settings best enabled only after testing

• Mobile display, if you have not yet checked the window width on small screens.
• Display on WooCommerce products, if you have not tested the cart, quick view, and theme pop-up elements.
• Display on forums and user-facing pages, if you have not checked user roles, login flow, and private sections.
• Embedding complex third-party scripts, if they have not been tested separately in a normal page block.

Timer or scroll: how to choose the display logic

One of the product-specific features in Progress Ads is the choice of trigger type. The description mentions two approaches: a countdown-based trigger and a scroll-position trigger. This is not just a technical setting. The trigger you choose shapes whether the visitor experiences the ad as a predictable pause or as an unexpected obstacle.

Countdown for a controlled start

A timer works well when the ad screen should appear after a clear interval from page load. It is easier to test because you know exactly how many seconds should pass before the window appears, and that makes the first-visit check quick. But a timer has a downside: it does not know whether the person is actually reading the page, switched to another tab, or has not even had time to see the content yet.

Use countdown mode carefully. If the window appears immediately after a visitor arrives from search, it may feel like an intrusive interstitial. That is especially sensitive on mobile traffic: a small screen, a slower network, and a full-screen ad can quickly create the impression that the site is getting in the way of the answer.

Scroll-based display for long-form content

A scroll-position trigger is usually a better fit for a long article or guide. The visitor has already started reading, so the window appears after some interaction rather than before any exposure to the content. That makes the experience feel more like a natural pause, especially if the ad screen does not appear in the first viewport but only after a meaningful portion of the page.

When configuring scroll-based display, avoid triggering the window at the moment the visitor is about to click a link, open a gallery, or interact with a form. Test the page manually: scroll slowly on desktop, then on mobile, then with a cookie banner and chat widget enabled. If the window opens at the exact moment the visitor is already trying to do something, move the trigger later.

How to choose between the two modes

What to place inside the ad window

The Progress Ads listing says the modal window can contain ads, contact forms, email forms, custom code, video, HTML, and shortcodes. That gives you flexibility, but it also requires careful choices. The content inside the window should fit the wait-based format: short, clear, not prone to accidental clicks, and not likely to break the layout.

Custom banner or promo block

The safest option for a first rollout is your own banner, promo message, or HTML block that does not depend on an external ad network. It is easier to troubleshoot, it does not create conflicts with AdSense policies around pre-roll and pop-up placement, and if something goes wrong you can replace the content quickly.

A good banner for this kind of window should communicate one idea: what is being offered and what the visitor should do next. Do not turn the window into a long sales page with tiny text, multiple buttons, and aggressive flashing elements. The ad screen is already prominent enough on its own.

AdSense and other ad networks

If you plan to show Google AdSense inside a forced-wait or pre-roll-like window, stop and review the placement policies first. AdSense policies include restrictions on showing ads before access to content and on pop-up/pop-under-style behavior. For that reason, this kind of format is usually safer with your own promos, direct campaigns, or networks whose policies explicitly allow the scenario you are using.

If AdSense is being used in a different, non-blocking mode, test it separately: first in a regular page block, then inside the modal window, and then with cache and JavaScript optimization enabled. Empty space inside the window does not always mean Progress Ads is at fault. It may be caused by no ad fill, an incorrect unit ID, delayed ad code loading, or an ad blocker.

Video and shortcodes

Video can work for a short promo, but mobile browsers often restrict autoplay with sound. If the window contains a video, do not assume autoplay will always work. It is better to design the flow so the visitor sees a clear static frame and can continue without being forced to watch playback.

Shortcodes are useful if you need to display a form, coupon, subscription block, or content from another plugin. But before inserting a shortcode into Progress Ads, test it on a normal page first. If the shortcode does not work outside the modal, it will not suddenly become more reliable inside it. If it works only with errors inside the window, look for a script conflict, a dependency on container width, or a JavaScript re-initialization issue.

Who should see the ads and where

One of the interesting parts of Progress Ads is that it can take post types into account and disable display for logged-in users. That helps you avoid showing the same ad screen to everyone indiscriminately. If the site monetizes non-logged-in traffic while regular community members are already signed in, disabling the ads for logged-in users can noticeably improve the experience for your core audience.

Post types and integrations

In WordPress, a post type is not just a "post" or a "page." WooCommerce adds products, bbPress adds forum entities, Easy Digital Downloads adds digital products, and Elementor can affect templates and layouts. According to the CodeCanyon product page, the plugin recognizes available post types and lets you enable or disable display in the right places.

The practical approach is to start with just one content type. For example, regular posts. After that works, you can test products, forums, or pages separately. Do not assume the same settings will transfer cleanly: modal behavior on a long article and on a product page can be radically different.

Logged-in users

Disabling ads for logged-in users is especially useful on sites with subscriptions, forums, account areas, stores, or gated content. A user who has already registered or signed in is often more valuable than a casual visitor. Making that person sit through the same wait screen on every page can be a poor tradeoff.

If the site has an account area, start by disabling display for logged-in users. Then decide separately whether the ad screen is appropriate for new visitors, forum guests, or users who have not yet completed a key action.

Mobile settings

Mobile settings were added as a separate enhancement in the plugin's change history, and that makes sense: on a phone, a modal window feels very different. Even a carefully designed desktop block can become too tall, the skip button can disappear under a bottom bar, and fixed-width ad code can overflow the screen.

Test at least three widths: a narrow smartphone, a medium smartphone, and a tablet. At each width, make sure the progress bar is visible, the skip button is accessible, the window does not shift sideways, the background does not scroll unpredictably, and the visitor can return to the content without reloading the page.

Practical example: a gentle skippable ad on a long article

Let us walk through a scenario that works well for a first test: the site publishes long tutorials and wants to show a custom promo block before the visitor continues reading. The goal is not to squeeze out the maximum number of impressions, but to verify that the format works without sharply degrading the user experience.

Goal

Show the ad window only on standard blog posts, while leaving pages, products, the cart, the account area, and logged-in users untouched. The window should appear only after the visitor has started reading the content, not immediately when the page opens.

Preparation

• Create a test post or choose one existing article with substantial text.
• Prepare a custom promo block without any external ad code: a headline, short copy, an image, or a link.
• Clear the site cache and temporarily disable aggressive JavaScript optimization on the test page if that is possible.
• Open the page in a separate browser or incognito mode to test the behavior of a non-logged-in visitor.

Setup steps

1. Enable Progress Ads only for the post type used for blog articles.
2. Disable display for logged-in users if that setting is available in your version.
3. Choose a scroll-based trigger so the window appears after reading has already begun.
4. Set a short wait time before the skip becomes available.
5. Configure the display frequency so the visitor does not see the window on every page.
6. Style the window to match the site while keeping a clear continue button and an obvious ad label.
7. Save the changes and open the test post as a regular visitor.

Checking the result

On the first visit, the window should appear at the expected moment, the progress state should be visible, the skip button should become available after the wait, and once the window is closed the visitor should return to the same place on the page or to a normal reading state. On a repeat visit, the window should not come back too quickly if you configured a frequency limit.

Then test the mobile screen. If the window covers the entire screen before the first paragraph is even visible, reduce the aggressiveness: move the trigger to a later scroll point, reduce the window height, disable it on narrow screens, or replace the flow with a regular banner.

A detail people often miss

If you test as an administrator, the result may differ from what a regular visitor sees. A logged-in user may be excluded from display, and cache may serve a different page version to administrators. That is why the final check should be done in incognito mode, without ad-blocking extensions, and with cache cleared.

How to verify that the ad is not breaking the page

Result verification is a separate stage, not a formality after saving the settings. Modal ad windows have several common failure points: the script does not load, the window appears behind the header, the page jumps when it opens, the close button is inaccessible, the frequency setting does not persist, or the ad code inside the window stays empty.

First-visit check

Open the selected page as a new visitor. If you chose a timer, measure how long it takes for the window to appear. If you chose scroll-based display, scroll slowly and see whether the opening point matches the intended logic. The window should open once and should not create duplicate overlays when part of the page refreshes.

Repeat-visit check

Close the window, move to another page, and come back. If a frequency limit is configured, the repeat display should follow the interval you selected. If the window keeps appearing again on every click, either the interval is too short or the site is not properly saving its cookie/localStorage state. If the site uses a consent banner, test the behavior both before and after cookie acceptance.

Mobile version check

On a smartphone, test more than just appearance. Test whether the actions are actually usable. The skip button should be tappable, the window should not cover browser UI elements, the background should not scroll independently from the modal, and the ad block should not overflow the screen width. If the site has a fixed bottom bar, make sure it is not covering the button.

Speed and console check

Open the browser developer tools and inspect the console. Errors such as jQuery is not defined, ad-code errors, or blocked-resource messages will help you determine more quickly whether the issue is in Progress Ads, JavaScript optimization, or the ad network. Then repeat the test with cache enabled, because the cached version is usually what real visitors see.

A good test result - the visitor sees the window at the expected moment, understands that it is an ad or promo, can skip it, does not lose their place on the page, and does not get the same window on every navigation step.

Recommendations for ads, SEO, performance, and safety

Progress Ads touches several sensitive parts of a site at once: ad policy, user experience, JavaScript loading, and mobile behavior. That is why the setup should be evaluated not just by whether "the window appeared," but by what happens as a result.

AdSense and ad policies

If you use Google AdSense, do not place it in a flow where the ad is shown for a forced interval before the visitor can access the content until you are certain the format does not violate your ad network's policies. The official AdSense rules include separate restrictions for pre-roll-like placements and pop-up/pop-under behavior. With a Progress Ads window, it is safer to start with your own promo materials or direct ad campaigns where the placement terms are fully clear to you.

SEO and intrusive interstitials

Google Search Central recommends avoiding intrusive interstitials that cover the main content and make it harder for visitors to access the page. That does not mean every dialog is forbidden, but for an ad window the rule is simple: do not cover the main purpose of the page immediately on entry, especially for mobile traffic coming from search.

Performance and JavaScript optimization

The plugin is described as JavaScript-based, which is exactly why it is sensitive to optimization settings. Delaying scripts can improve speed metrics, but it can also break flows that are supposed to start on a timer or scroll position. If the window does not appear, appears too late, or the button does not work, the first thing to try is temporarily excluding the plugin scripts and ad-network scripts from delay/minify on the test page.

Safe improvement without code

This guide does not include a PHP or JavaScript snippet because there is no confirmed public set of Progress Ads hooks or filters that would be safe to rely on. In practice, it is more useful to work through the plugin settings, cache settings, a child theme for minor CSS adjustments, and careful page targeting. Any direct edits to plugin files should be treated as temporary and risky.

If the problem can be solved by adjusting display logic, frequency, mobile mode, or excluding a script from optimization, do not start by editing code. That is easier to roll back and safer for future updates.

When CodeCanyon Progress Ads is worth using

Progress Ads is a strong fit if you do not need a universal ad dashboard but a very specific format: a modal window with a progress indicator, wait time, skip behavior, frequency control, and post type targeting. It is especially well suited to careful testing on long-form content, promo pages, and non-logged-in traffic where an ad pause does not interfere with purchasing, signing in, support access, or reading critical content.

If you have already defined a safe test area, reviewed your ad network rules, prepared a rollback plan, and decided what will go inside the window, you can get the WordPress version and begin with one controlled scenario. After the first rollout, evaluate more than just impressions: also watch complaints, bounce behavior, mobile interaction, console errors, and repeat visits.

The best outcome for a plugin like this is not the maximum number of impressions, but a predictable ad flow that the visitor can skip quickly and that does not break the page's core purpose. If that feels too aggressive for your site, go with regular banners, after-paragraph placements, or a full ad placement manager instead.