Bidsopt DSP

Login to Bidsopt DSP

To login to your dashboard, follow the below steps

  1. From the homepage, please navigate to login button or click here
  2. Enter your email id or username and password
  3. Click on Sign In Button

New User Sign up

  1. To sign up as a new user, please navigate to
  2. Enter your details and click on sign up
  3. Once you sign up, Bidsopt account manager will verify your account and approve it.
  4. Once the account is approved, you will get a notification mail to sign in to your account

How to run a campaign?

Campaign building
  • A CPA campaign – to catch the media that allows buying on CPA
  • A CPC campaign – to catch most other media that is not available on CPA
  • Build this campaign with a low base CPC price
  • Have specific bids on segments that work better
  • A CPM campaign – usually at later stages in which you know exactly how much to pay for each segment. This allows buying the media for lower overall price and allows using generic banners
Campaign lifecycle
  1. Probing
  2. Discovery
  3. Optimization
  4. Growth
1) Probing
  • Challenge - Find out if the traffic source has any potential
  • Method - Buy in very low prices
2) Discovery
  • Challenge - Find out if the full potential is of as many publishers and media as possible
  • Method -
    • Increase prices
    • Buy very wide
    • Aim for an ROI of 20% for the first 500 conversions, i.e. the budget should be 500 x CPA goal x 5
    • Run exclusion optimization (remove things that do not work) and use additional 500 conversions to get to 50% ROI
3) Optimization
  • Challenge - Get to 100% ROI
  • Method - Run price optimization on all traffic matrices
4) Growth
  • Challenge - Increase the size of the campaign
  • Method -
    • Run Probing, Discovery and Optimization on additional traffic sources
    • Identify segments of solid behaviour and buy their media in CPM
Optimization best practices (A)
  • Try to buy as much media as possible on CPM
  • Refresh the content constantly (creative and landing pages)
  • Use specific bids
  • Use multiple landing pages to A/B test them
Optimization best practices (B)
  • Common optimization matrices
  • Publisher and placement / External publisher
  • Day of week
  • Channel – CPI campaigns
  • Browser – CPI campaigns
  • Device type – CPI campaigns
  • Make/model – mobile subscription campaigns
  • Find what IPs are working and target them – mobile subscription campaigns
  • Region – mobile subscription campaigns
  • OS version – CPI campaigns

Bidsopt Dashboard

Bidospt dashboard consists of different tabs, graphs and reporting sections.

How to test a tag?

To login to your dashboard, follow the below stepsTo test a tag please visit following URL

Test A Tag is a service designed to preview ad tags/creatives on the fly and on various browsers directly. It supports both HTML tags for banner creatives and VAST tags for video, relying on Google’s IMA SDK for the latter. The service was designed to make previewing a creative a little easier for ad ops and clients alike.

Utmost care has been taken to ensure that a creative shows up as it was intended to. However, due to the many adservers, measurement, ad verification and blocking services intermediaries, the actual creative corresponding to a tag may appear different when tested on different domains or devices. Specifically, but not necessarily for all creatives, the domain may need to be whitelisted on services that block ads based on domains.

What are VAST and VPAID?


VAST is a Video Ad Serving Template for structuring ad tags that serve ads to video players. Using an XML schema, VAST transfers important metadata about an ad from the ad server to a video player. Initially launched in 2008, VAST has since played an important role in the growth of the digital video marketplace.

The early days of video consisted mostly of shared videos and other user-generated content. Success in monetizing this content with ads has produced the resources to improve the digital video marketplace. However, digital video has met a number of challenges along the way.

One challenge is a lack of quality control. Along with the IAB Video Player-Ad Interface Definition (VPAID), VAST can deliver ads programmatically or include ads with complex interactions. If a player isn’t programmed to accept VPAID ads, the ad cannot be executed. Even when the player does accept VPAID ads, performance may be slow and cause latency in load times. In the meantime, the audience experiences a delay or a malfunction in their viewing experience.

Publishers and ad vendors need a way to separate the video file from its interactive components to ensure that ads play in systems that cannot execute the interactive components. These ads should also execute more efficiently in players that are equipped to handle the interactions.

Another challenge, especially for broadcasters who are moving their content online, is the lack of a consistent identifier for creative that is maintained across systems. VAST offers a creative identifier, but it has been used inconsistently and one creative may use different identifiers for every system it passes through. A system-wide identifier is a requirement for broadcasters trying to maintain control over the ads they play.

VAST 4.0 has addressed these challenges along with a few others. As players begin to adopt the updates in VAST 4.0, digital video can expect to see smoother operation and continued growth.


The IAB’s Video Player Ad Interface Definition (VPAID) establishes a common interface between video players and ad units, enabling a rich interactive in-stream ad experience.

In-stream video advertisers have two important execution goals for the delivery of their video ad campaigns: a) provide viewers a rich ad experience, and b) capture ad playback and user-interaction details that report on the viewed ad experience. To achieve these goals in a world without common video player functionality, advertisers would have to develop multiple specialized versions of their ad creative for every unique video player—an expensive proposition that doesn’t scale well.

The Video Ad-Serving Template (VAST), another IAB specification, provides a common ad response format for video players that enables video ads to be served across all compliant video players. However, VAST alone does not provide support for rich interactivity. VAST alone only supports relatively simple in-stream video ad formats that are not executable. These simple ad formats do not provide an interactive user experience, and do not allow the advertiser to collect rich interaction details.

Layering VPAID onto VAST offers an enhanced solution. VPAID establishes a common communication protocol between video players and ad units that allows a single “executable ad” (one that requires software logic to be executed as part of ad playback) to be displayed in-stream with the publisher’s video content, in any compliant video player. Furthermore, it enables the executable ad unit to expect and rely upon a common set of functionality from the video player. VPAID enables the video player to expect and rely upon a common set of functionality from the executable ad unit. The significance is that advertisers using VPAID ads can provide rich ad experiences for viewers and collect ad playback and interaction details that are just as rich as the ad experience. With the adoption of VPAID, advertisers have more control over the display experience in their video campaigns. Also, as VPAID compliant video players enable a more diverse and interactive set of video advertising, VPAID compliant publishers should expect to sell more instream video inventory. With VPAID, the IAB aims to address the following market inefficiencies for publishers, advertisers, and vendors by:

  • Increasing common video ad supply technology so that video publishers can readily accept video ad serving from agency ad servers and networks;
  • Providing common technology specifications for advertisers to develop against, thereby decreasing the cost of creative production and thus increasing business ROI;
  • Improving video ad supply liquidity, thus decreasing the cost of integration with each publisher.

To improve the interactive ad experience in video players, publishers should build their video players to the VPAID specifications outlined in this document. These specifications were defined with creativity and innovation in mind and should not limit video player design. As with all IAB guidelines and specifications, this document will be updated as video advertising progresses and new ad formats become more widely adopted.

Video Support

List of supported SSPs and Supported Ad Formats

Conversion Tracking: The Basics

Conversion pixels let you track the success of your campaign by reporting back when the user completes an action on your website after arriving through an advertisement. Not only will conversion tracking tell you how many times this action has been completed, but it will also allow you to attach a dollar value to that action for revenue reporting. Once conversion pixels are placed, you can see how many conversions are generated from each site, placement, banner, etc. Conversion pixels can be used to track actions such as these:

  • User makes a purchase.
  • User signs up for your site.
  • User submits their e-mail address.
  • User arrives at your “goal page.”
  • Any other event or action on your website.
How It Works

A conversion pixel is a short line of code that advertisers place on their conversion pages (e.g. “thank you” pages). Bidsopt DSP keeps track of the impressions and clicks that occur for your campaigns, and these events are tied to a click ID (such as a cookie ID, Transaction ID, etc.).

When the user clicks one of the ads in the campaign, a cookie is placed on that user’s browser. That cookie records the time, domain, placement, creative, etc. that the user clicked.

Later, when the user arrives at the advertiser’s thank you page and the browser loads the conversion pixel, the Bidsopt server looks up the click ID for the list of impressions and clicks that have occurred for the user recently. If there is a match between a conversion pixel and a campaign, the conversion is attributed to the most recent click that occurred.

Setting Up Conversion Tracking (Conversion Pixel Tracking)

Conversion pixels count the number of users that completed a particular action on your website and attribute that conversion information back to the tactic.

Step 1:

Create a campaign and ads from Bidsopt dashboard. While creating the ads we need to append Bidsopt click id macro to the landing page to track the conversion

Where bo_ck is Bidsopt click macro.

Bidsopt does support additional macros to send like pub id, advertiser id, campaign id…where the client can track at their end for their optimization:

We can also track additional parameters if we pass additional values in the click tracking URL. Currently, we support aff_sub1, aff_sub2 and aff_sub3


We should be able to track above macro details in our conversion reports

Step 2:

Place the Pixel on Your Landing Page or Website

Note: You must place the pixel within the BODY section of your webpage. If you do not place the code between the opening and closing BODY tags, then the pixel script will not run.

<script src=""> </script>
<script type="text/javascript">cnvTrack(15);</script>

In above landing page pixel, please check ” cnvTrack(15)“- Here 15 represents the number of days we can keep the conversion window. Change this number according to the campaign requirement.

Place the second script in the conversion page

If the conversion event is a form submission or click – the script should invoke once the conversion event has happened.

Postback Conversion Tracking

With postback conversion tracking, you can see conversion reporting in Bidsopt DSP without having to rely on browser cookies. This lets you track conversions even when you cannot place a conversion pixel or when the conversion happens outside of a browser. Examples include an affiliate network tracking platform like Tune or an app tracking platform like AppsFlyer.

When you use postbacks, you configure Bidsopt DSP and your tracking platform to send the right information to each other:

  • The Bidsopt DSP campaign’s click URL sends the postback ID(click id aka transaction id) to the tracking platform.
  • The tracking platform sends the postback ID to Bidsopt DSP when a conversion takes place.
How It Works

Postback conversion tracking uses server-to-server calls to pass information between two systems: Bidsopt and a tracking platform.

As an example, let’s say we want to track app installations as our conversion. Since app installs don’t happen in a web browser, we can’t use a conversion pixel. Instead, we need an app tracking platform, which can determine when the conversion takes place, attribute the conversion to a click, and then report the conversion to Bidsopt DSP using a postback.

Before the campaign runs:

  • The app developer chooses a tracking vendor and installs its SDK when she designs the app. She writes the app so that it makes a call to the tracking vendor when it first opens.
  • In the tracking vendor’s UI, someone configures the postback. Usually, this is done by simply selecting Bidsopt DSP from a list and entering the details from the previous step. The tracking vendor will supply a click URL to be used for the campaign.
  • The Bidospt DSP user uses this click URL as the destination URL for the ads. It is populated with macros that cause Bidsopt DSP to pass important values including the postback ID to the tracking vendor on click.
Setup Overview

The setup steps on both the tracking vendor side and DSP side are all essential for postback tracking to work: essential information must flow in both directions from one system to the other. The following steps are written from the perspective of the DSP user.

1. Determine which tracking vendor will be used for the campaign.

You need to inquire with the agency or app publisher that you are running the campaign for. If you are also the app publisher, then you or a colleague should know what tracking vendor you use.

Setup is simplified for many tracking vendors, as they provide templates for ease of implementation. If a tracking vendor does not offer a template for Bidsopt DSP, you can request this by contacting DSP support and introducing us to an appropriate person at the tracking vendor – most vendors are happy to do this.

2. If any of the vendors do not give a tracking template we use below postback details

Postback URL{click_id}&aff_sub1={pub_clickid_value}

Where clickid is your placeholder name where we will pass our value in the landing page URL. You need to post back the same to us through the above postback integration.

Sample Postback Response:

Sample Landing page URL:


where bo_ck is Bidsopt click macro.

Bidsopt does support additional macros to send like pub id, advertiser id, campaign id…where the client can track at their end for their optimization:

Banner Ad Macros:

bo_cid === Bidsopt Client ID for App or Website (it is pub id)

bo_advertiser_id === Bidsopt Advertiser ID

bo_campaign_id === Bidsopt Campaign ID

bo_strategy_id === Bidsopt Strategy ID

bo_udid_key === Bidsopt User device identifier collected (it may be ifa or ifa_md5 etc..)

bo_udid_val === Bidsopt User device identifier value

bo_ip === IP Address

bo_mobile_model === Mobile Model

bo_publisher_id === Bidsopt Publisher Identifier

bo_ck ====== Bidsopt Click Identifier

TAG Macros:

$bo_ck ==== For click tracking at third party TAGs

$bo_cid === Bidsopt Client ID for App or Website (it is pub id)

$bo_cb ====== Bidsopt Cache Buffer

$bo_impression_id === Bidsopt Impression Id

Affiliate Tracking

We can track the conversion and post back the same conversion to publishers. Please note this option is not available for self-service advertisers. For more information please contact your account manager.

Step 1: Create an ad client and add the client post back URL

aff_sub1 is the macro used by Bidsopt to pass the value of publisher click id

Step 2: Let the advertiser setup our postback or conversion pixel in their system

Postback Method{click_id}&aff_sub1={aff_sub1}

click_id is the placeholder name used by Bidsopt to represent click id ( transaction id)

aff_sub1 is the placeholder used by Bidsopt to pass the value of publisher click id

The advertiser need to replace the value of click_id and aff_sub1 from the click generated by Bidsopt Please visit the postback integration documents for more information

Conversion Pixel Method

If the advertiser uses our conversion pixel, they just need to follow the step outlined in the conversion pixel documents.

Step 3: Create a campaign in Bidsopt dashboard and target specific publishers

bo_ck is Bidsopt macro to pass the click id (transaction id)

bo_aff_sub1 – this macro will replace the value of publisher click id

Step 4: Generate a click URL from the dashboard

Add our additional macros to pass the conversion postback to the publisher as below{insertyourclickid}
Step 5

Ask Publisher to test at his end or get a test link from them to test at our end.

Step 6

Check click log and conversion log, if the aff_sub1 column stores publishers click id and matches.

Integrated Exchanges

Bidsopt DSP is a Demand Side Platform (DSP) that plugs into ad exchanges/Supply Side Platforms (SSPs) (e.g. MoPub, Rubicon, Pubmatic) and makes their publisher inventory available to advertisers through a transparent and manageable interface. Each time an impression becomes available on one of the exchanges, it is available to users of Bidsopt DSP via an auction/bidding model. When an impression becomes available, advertisers on Bidospt DSP bid on that impression. Basis DSP sends the winning bid to the exchange, where the winning advertiser bids against other DSPs on that exchange. If that advertiser has the highest bid, the impression will be delivered.

Bidsopt DSP is connected to all major inventory sources, and we are creating new and exciting exchange partnerships all the time.

To view the sum of our current exchange integrations, click the Supply tab after logging into Bidsopt DSP. By selecting the Exchanges menu, you will see an up-to-date list of the exchanges available.

Below is the list of Exchanges available

SSP Geos Opened Adsize Traffic Type OS Desktop Native Pop
Waardex DE,CH,AT,FR,MY,HK,SG 300x250 Both Both Yes Yes No
Mopub AE AU BE BG BH CA CO HK ID IN IQ IT JO JP KR KW LB MY OM QA RU SA UK US ZA300x250, 320x50, 320x480, 480x320InAppBoth No Yes No
Gothamads US HK IN IQ BH JO SA AE LB OM KW QA FR DE CH SG MY IE MY RU CA AT GB IT BE 300x250, 320x50, 320x480, 480x320 Both Both Yes Yes No
Axonix US, SG, AE, BH, KW,SA, LB, AE, OM, JO, QA, IN, HK, US, IQ 300x250, 320x50, 320x480, 480x320 Both Both Yes - No
Brave ALL Geo 300x250, 320x50, 320x480, 480x320 Both Both Yes Yes No
Xendiz US, SG, AE, BH, KW,SA, LB, AE, OM, JO, QA, IN, HK, US, IQ 300x250, 320x50, 320x480, 480x320 Both Both Yes Yes No
Mobfox CA AU QA IQ BH OM ID MM MY KR HK RU KW SA AE US FR DE CH SG 300x250, 320x50, 320x480, 480x320 InApp Both No Yes No
Smaato BH, KW,SA, LB, AE, OM, JO, QA, IN, HK, US, IQ 300x250, 320x50, 320x480, 480x320 Both Both Yes Yes No
Mobupps US, SG, AE, BH, KW,SA, LB, AE, OM, JO, QA, IN, HK, US, IQ 300x250, 320x50, 320x480, 480x320 Both Both Yes Yes No
Rhythomone BH, KW,SA, LB, AE, OM, JO, QA, IN, HK, US, IQ 300x250, 320x50, 320x480, 480x320, 728x90, 768x1024 Both Both Yes - No
Bidswitch US HK IN IQ BH JO SA AE LB OM KW QA FR DE CH SG MY IE MY RU CA AT GB IT BE 300x50, 300x250, 320x50, 320x480, 480x320, 768x1024 Both Both Yes Yes No

Available Inventory

By default, the Ad client tab displays all available domains and apps on Bidsopt DSP. You can search the desired app or site list from the app list. You can contact your account manager for more details on inventory available with Bidsopt DSP

Supported List of JS, and Tag Macros

Macro Description
$bo_click Click URL
$bo_ck Click Id
$bo_cb Cache Buster
$bo_impression_id Bid Id
$bo_cid Adclient Id
$bo_udid_val Device Id
$bo_ip Ip Address
$bo_adc_domain Name Of The Adclient
$bo_exchange Ssp Name
$bo_adc_name Name Of The Adclient
$bo_adc_cat Adclient Category
$bo_bundle Bundle Of The App
$bo_crid Creative Id
$bo_carrier Name Of The Carrier
$bo_country Country code
$bo_ver_os Os Version
$bo_manufacturer Name Of The Device
$bo_model Mobile Model
$bo_lang Language Of The Device
$bo_advertiser_id Advertiser Id
$bo_lat Latitude
$bo_lon Longitude
$bo_camp_id Campaign Id
$bo_storeurl App Store URL
$bo_click_enc Encoded click url

Supported List of Banner Macros

Macro Description
bo_click Click URL
bo_ck Click Id
bo_cb Cache Buster
bo_impression_id Bid Id
bo_cid Adclient Id
bo_udid_val Device Id
bo_ip Ip Address
bo_adc_domain Name Of The Adclient
bo_exchange Ssp Name
bo_adc_name Name Of The Adclient
bo_adc_cat Adclient Category
bo_bundle Bundle Of The App
bo_crid Creative Id
bo_carrier Name Of The Carrier
bo_country Country code
bo_ver_os Os Version
bo_manufacturer Name Of The Device
bo_model Mobile Model
bo_lang Language Of The Device
bo_advertiser_id Advertiser Id
bo_lat Latitude
bo_lon Longitude
bo_camp_id Campaign Id
bo_storeurl App Store URL
bo_click_enc Encoded click url

Supported List of Native Video Macros

Macro Description
bo_v_pw Creative Width
bo_v_ph Creative Height
bo_v_ip Ip Address
bo_v_ua Device User-Agent
$bo_click Click URL
$bo_ck Click Id
$bo_cb Cache Buster
$bo_impression_id Bid Id
$bo_cid Adclient Id
$bo_udid_val Device Id
$bo_ip Ip Address
$bo_adc_domain Name Of The Adclient
$bo_exchange Ssp Name
$bo_adc_name Name Of The Adclient
$bo_adc_cat Adclient Category
$bo_bundle Bundle Of The App
$bo_crid Creative Id
$bo_carrier Name Of The Carrier
$bo_country Country code
$bo_ver_os Os Version
$bo_manufacturer Name Of The Device
$bo_model Mobile Model
$bo_lang Language Of The Device
$bo_advertiser_id Advertiser Id
$bo_lat Latitude
$bo_lon Longitude
$bo_camp_id Campaign Id
$bo_storeurl App Store URL
$bo_click_enc Encoded click url

Supported List of Direct Link Macros

Macro Description
$bo_cid Adclient Id
$bo_advertiser_id Advertiser Id
$bo_campaign_id Campaign Id
$bo_impression_id bid Id
$bo_udid_val Device Id
$bo_ip Ip Address
$bo_device_model Name of the device
$bo_mobile_model Mobile Model
$bo_lang Language Of The Device
$bo_ver_os Os Version
$bo_os Os Name
bo_publisher_id Publisher Id
bo_ua user agent
bo_ck click id
$bo_carrier Name Of The Carrier
$bo_country Country code
$bo_manufacturer Name Of The Device
$bo_model Mobile Model
$bo_crid creative id
$bo_lat Latitude
$bo_lon Longitude
bo_exchange SSP Name
bo_adc_domain Domain Of The Ad client (for Site)
bo_bundle Bundle Of The App
bo_aff1 Extra prams
bo_aff_sub1 Extra prams
bo_aff_sub2 Extra prams
bo_aff_sub3 Extra prams
bo_aff_sub4 Extra prams
bo_aff_sub5 Extra prams

Click Tracking for RTBPlay Domain

Macro Description
rp_click click url
$rp_click click url for tags
rp_click_enc encoded click url
$rp_click_enc encoded click url

Add macros to third-party ad tags

Bidsopt DSP is compatible with a wide range of third-party ad servers. A number of click tracking and cache-busting macros can be used to allow these third parties to track clicks for creatives served through Bidsopt DSP

When you add a third-party ad tag to Bidsopt DSP, you’ll have to insert the macros yourself. Each third party tag looks a little different, but you can use the samples below as a guide.

What is a macro?

macro is a placeholder (for example:$bo_click) that an ad server replaces with real value when the creative serves. Use macros in your tags when you want Bidsopt DSP to insert information into the tag in real-time.

For example, let’s say you’re using this third-party ad tag:

type="text/javascript" src=""

The third-party ad server expects a Bidsopt DSP click tracking URL after “click=“. To get this URL, insert a click tracking macro in the tag:

type="text/javascript" src="$bo_click"

Each time the ad is served, the placeholder $bo_click is replaced with the actual click tracking URL from Bidsopt DSP.

Click tracking and cache-busting macros

Click tracking macros are the most commonly used type of macro. These macros allow third-party ad servers to track a click and associate it with the correct creative, line item, and auction in Bidsopt DSP. Clicking on a creative will first direct users to the Bidospt DSP ad server (to record the click and associated auction information) before redirecting them to the advertiser’s URL.

We also support additional macros depends on the advertiser purpose. The complete list of macros can be found here

Third Party Impression Trackers

You can use different third party impression trackers in Bidsopt DSP. Examples of third party trackers are Moat, Fraudlogix & DCM Trackers etc.

Below is the sample Moat Tracker:

Sometimes thirdparty trackers are given as URL format

Tracker url :