> For the complete documentation index, see [llms.txt](https://docs.exoclick.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.exoclick.com/tutorials/tutorials/publishers-tutorials/dynamically-block-ad-types-for-exoclick-in-stream-zones.md).
# How to dynamically block ad types for ExoClick In-stream (video) zones
In this tutorial, we’ll demonstrate how to dynamically **block** ***Video (In-Stream)*** ad campaigns based on ad type.
This approach can be implemented across various scenarios, but a common application is to use this technique when you, as a publisher, want to show certain types of ads to users who provide consent, while blocking specific campaigns for those who don't accept your website's terms and conditions.
To illustrate this idea, we’ve created two code snippets using vanilla JS. In the first one, we demonstrate how to block video ads based on URL parameters. The second example simulates a case in which user consent is stored in the browser’s local storage. In both cases, we’re leveraging Exoclick’s `block-ad-types` feature.
In order to display In-Stream ads, we're using [Fluid Player](https://www.fluidplayer.com/), a free, open-source HTML5 player that is compatible with VAST and VPAID formats.
> Bear in mind that if you have a different setup, you will have to adapt this code to suit your player requirements. However, the core logic for the `block-ad-types` feature remains the same.
## EXAMPLE 1 - Block In-Stream ad types based on URL Parameter
This is a fairly straightforward logic that doesn't differ much from a basic Fluid Player integration, in which a standard video player is loaded first, and then Fluid Player is attached to it.
The main difference here is that, before attaching Fluid Player to the standard video player, we perform a URL parameter check, where we retrieve the value for `user_verified`.
With that defined, we have an if statement that sets the `dynamicVastTag` variable to either block NSFW ads for unverified users or allow all ads for verified users.
Once this variable is set, we proceed to load the Fluid Player config object, making sure to include the `dynamicVastTag` variable as a value for the `vastTag` property.
```html
In Stream (video) ads | block-ad-types
block-ad-types for In Stream (video) ads using URL params
```
## EXAMPLE 2 - Block In Stream ad types based on local storage data
This implementation differs from the previous one by using local storage to manage user consent instead of URL parameters. The code is modular, with separate functions for creating the video player and the Fluid Player configuration.
The `` section of the HTML contains three main functions that control ad serving based on user consent:
* ***`insertVideoPlayer`*** creates a video player element and adds it to the webpage.
* ***`fluidPlayerConfig`*** generates a configuration object for Fluid Player. This function's key logic is in how it chooses the ad URL: if the user hasn't accepted the terms (false), it adds `&block_ad_types=101` to the URL to block certain ads. If the user has accepted (true), it uses the standard URL, allowing all ads.
* ***`insertFluidPlayer`*** ties everything together. It first creates the video player using insertVideoPlayer and then attaches Fluid Player to it, using the specific configuration from playerConfig that's tailored to the user's consent.
In the ``, the final script checks local storage for user consent on page load and renders the players accordingly. If no consent was given but the user later accepts the terms by clicking the button, the player is reinitialized with the updated permissions.
```html
In Stream (video) ads | block-ad-types
block-ad-types for In Stream (video) ads using local storage
```
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.exoclick.com/tutorials/tutorials/publishers-tutorials/dynamically-block-ad-types-for-exoclick-in-stream-zones.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.