Objective -
Integrate Hockeycurve to enable interactive ads with audio, video, and animations, enhancing engagement across prominent ad placements.
Context -
Hockeycurve enables dynamic creative rendering via a single ad tag, allowing real-time personalization using 3P API integrations (e.g., live cricket scores, temperature, gold rates, NIFTY index, etc.). These moment-based campaigns leverage dynamic layouts and support composite widget formats like video + product carousels.
With a capacity of 1.5 lakh QPS, Hockeycurve’s rich media ads on high-visibility placements deliver strong engagement, unlocking an estimated ₹67 lakh/month ad revenue opportunity.
Campaign types supported by HC - Ad tag details -
The ad tag is a responsive <iframe> or <xml>, capable of serving ~150 customizable creative templates via a single URL, parameterized with campaign-specific macros. Below are the key components -
Sample Iframe :-<iframe id="25462_1" src="https://ad.hockeycurve.com/ad.php?zoneid=1440x720&client=ideas&tagid=25462&bcamp=gmynk8&fcat=gmynk8&partner=dbm&hct=masterv2&optout=false&bundle_id=${BUNDLE_ID}&dbmc=${CAMPAIGN_ID}&usite_id=${UNIVERSAL_SITE_ID}&ct0=${CLICK_URL_ENC}&cb=${CACHEBUSTER}" frameborder="0" scrolling="no" style="width: 100%; height: auto; aspect-ratio: 1440 / 720; transform-origin: top left;"> </iframe> <script> function scaleIframe() { const iframe = document.getElementById("25462_1"); const containerWidth = iframe.offsetWidth; const scaleFactor = containerWidth / 1440; iframe.style.transform = `scale(${scaleFactor})`; iframe.style.height = `${720 * scaleFactor}px`; } window.addEventListener("load", scaleIframe); window.addEventListener("resize", scaleIframe); </script> Sample Tag 1 :- (3:1 Aspect Ratio) for ATF (Banner 3.0 Widget) <div style="width:100%;aspect-ratio:3/1;overflow:hidden">
<iframe id="25462_0" src="" scrolling="no" width="1440px" height="480px" style="transform-origin:top left">
</iframe>
</div>
<script>
function scaleIframe() { const iframe = document.getElementById("25462_0"); const containerWidth = window.innerWidth; iframe.style.scale=containerWidth / 1440; } window.addEventListener("load", scaleIframe); window.addEventListener("resize", scaleIframe);
</script> Sample Tag2 :- (2:1 Aspect Ratio) for BTF (Banner 2.0 Widget) <div style="width:100%;aspect-ratio:2/1;overflow:hidden">
<iframe id="25462_1" src="}" frameborder="0" scrolling="no" width="1440px" height="720px" style="transform-origin:top left">
</iframe>
</div>
<script>
function scaleIframe() { const iframe = document.getElementById("25462_1"); const containerWidth = window.innerWidth; iframe.style.scale=containerWidth / 1440; } window.addEventListener("load", scaleIframe); window.addEventListener("resize", scaleIframe);
</script> Ad tag Metadata -
${CLICK_URL_ENC} is a placeholder for the ad’s click tracking URL. In the ad tag, the click_macro will be replaced with the encoded version of:
The DSP substitutes ${CLICK_URL_ENC} with this tracking URL, appending the final landing page URL at the end. ${CACHEBUSTER}: A placeholder for a random number (or timestamp in seconds) to ensure that each ad tag looks unique and avoids caching issues. ${CAMPAIGN_ID}: A placeholder for the current campaign ID provided by the DSP. This helps customize the ad for the campaign and also allows tracking in analytics reports. bundle_id=${BUNDLE_ID}: Relevant for other DSPs, not for Paytm usite_id=${UNIVERSAL_SITE_ID}: Relevant for other DSPs, not for Paytm aspect-ratio: 1440 / 720; transform-origin: top left; Iframe AdTag Size: As confirmed by HockeyCurve, their AdTags size would approximately go till 1000 characters, which includes all essential parameters such as dynamic macros, tracking, and rendering logic.
Ad tag sourcing / finalisation
Paytm will share creative specifications—including widget dimensions, brand assets, landing page URL, and third-party tracking URLs—with Hockeycurve via a shared Google Sheet or Doc, sent over email. In case the Ad is not being rendered at the HC's end due to any issue, HC is supposed to render a fallback Ad. This fallback Ad creative is needed to be shared with HC along with the creative specifications. Hockeycurve will deliver iframe- or XML-based ad tags based on the specifications provided by Paytm. If any changes are required (e.g. design updates, landing URL, or tracking modifications), Paytm must inform Hockeycurve via email. Hockeycurve will then update the corresponding things for the iframe/ xml based ad tags which was provided by HC (The AdTag will not change). The AdTag will have below macros that needs to be configured by Paytm in their Ad Tag while configuring the campaign: ${CAMPAIGN_ID}: Unique ID of the campaign on which the particular creative (consisting AdTag) is attached. This is to be done when a campaign is being configured. ${CACHEBUSTER}: The timestamp when that particular ad (consisting AdTag) is being rendered on the FE. This is to be done by the App team when the Ad is being served. Ad tags will have the embed macro (${CLICK_URL_ENC}) for click tracking and analytics The Signal Tracking on these Ads (consisting Iframe AdTag) will work the same way that they are currently working in case of Banner/ Video Ads Ads Backend
Support ingestion of iframe, XML and Javascript based ad tags as a new creative format with preview functionality Tag parameter replacement - Populate campaign ID in $(CAMPAIGN_ID) property appropriately at the time of campaign configuration Validate the ad tag character size should not exceed 'X' character limits (To be aligned between Ads - SF BE - App FE) The iFrame should follow standard validation practices, including ensuring that all JavaScript and HTML code is fully contained within the iFrame. Additionally, the iFrame tag, including any ingested redirection URLs, must comply with Paytm’s EVT-based authentication workflow to ensure alignment with our security protocols. Validate that ad tag dimensions match the expected ad view size on which the iframe creative is being attached At the time of campaign configuration, ensure AdTag based creatives are only assigned to those views that support iframe rendering on the frontend Modify Ad Manager ↔ Ads Backend contract to support passing iframe tags as a new key value pair in Widget Serve response. Compression of Iframe code (removing beautification) before sharing at the time of serving. (To be aligned between Ads - SF BE - App FE) The Landing Type needs to be injested in display_metadata for WidgetServe response, to be used by FE to determine either Internal/ External/ embed redirection. In case the iframe Tag fail to render at the FE, HC will render the Fallback creative automatically. The fallback creative needs to be shared to HC along with the creative specifications. Support all existing Ad Manager features: user segmentation, ad tracking, macros. The Click & Impression tracking URLs working would follow the same, which is currently being done for Static/ Gif images & vidoes. The HC will trigger the given click tracking URL which will route to Paytm's evt and the corresponding macros present in the URL should be updated post the EVT-based authentication that currently being followed for Static/ Gif images & vidoes The Click & Impression tracking URLs working is expected to follow the same approach which is currently being used for static/GIF images and video creatives. HC will invoke the provided click tracking URL, which will route through Paytm’s EVT service. All macros embedded within the URL must be dynamically resolved and updated at the Ads end post successful EVT-based authentication, consistent with the current handling for static and video creatives. SF BE
Consume iframe/ xml - based creative data from Ads Implement fallback creative routing if the iframe/ xml Ad render failure Maintain compliance with privacy policies The Iframe AdTag will directly flow in an attribute value in the Ads Selection Service response (contract to be finalized and shared by Ads BE - SF BE teams) This will directly render on the FE, reducing the latency and higher performance. This may lead to higher Payload size, however, App currently have some attributes which comes in a longer character size, so this will not matter much. Any response minimization/ compression for a faster Payload response would have to be closely aligned with App FE, since changes to Payload can have ramification to rendering. Additionally the other approach (where the iframe would be shared in a file) would have lead to higher latency, though lower payload size, but would have affect app performance especially on the HomePage. App FE
Phase 1
In this phase, below Widgets are expected to support iframe rendering, especially on the HomePage & PTS screens.
Requirements for Phase 1
Support proper rendering of Iframe based AdTag (received from Ads in SF response) on the widgets which are scoped in the current Phase. Tag parameter replacement: Replace ${CACHEBUSTER} macro in the iframe AdTag with a unique timestamp representing when the Ad is actually served on the FE to avoid caching issues. HC confirmed that this will be managed at there end. In case the Ad failed to render, the fallback ad image provided by Paytm along with creative specifications will be rendered by HC. HC confirmed that they cannot directly share child-level clicks or interaction data with Paytm via any callbacks. All these data would be provided in their reports. All Parent clicks & Blind Impressions should be recorded inhouse Signal events/ reports 3rd Party Clicks Tracking URLs to be triggered once by Paytm when the Parent View will receive the click event from HC about the click redirection. For Impressions, the Blind Impressions should be recorded in Signal, as soon as the Iframe content is being loaded on the view. Instrumentation of Actual Impressions should be there when the Ads are being actually rendered on iFrame. (This will be done at HC's end) The 3rd Party impressions tracking URLs should be fired once at this moment. HC agreed to trigger these 3rd Party urls (if shared to them beforhand along with the creative specifications) when the Ad is actually being rendered. However the App team needs to check if this too can be handled somehow at the Paytm’s end in the way click tracking is to be done. (To be Aligned with App) Since, Paytm don't have the real data about what is clicked within the iframe child, the click redirection could not be managed at Paytm's end. The click redirection URLs will be shared to the HC beforehand along with the Ads requirement and they will embed them in the iframe that they will provide. App needs to route the user to Internal/ External/ embed, depending on Ads BE response. OM SDK Support (To be Aligned with App): HockeyCurve does not currently support OM SDK integration for tracking or measurement. App need to figure how the OM viewability tracking could be ensured at our end. To ensure a smooth user experience, particularly on placements like Home Page ATF, The iframe ad should render instantly when a user scrolls away and returns to the view. Avoid any blank screen or visible loading delay during re-entry. In oder to maintain this: The iframe should be Cached somehow after its initial load to enable quick re-renders. The ad should remain static unless the user interacts with it (e.g., tap or click) and refresh only upon direct user interaction. Very Low Internet / Poor Device Performance Handling App should monitor the rendering time of iframe ads on each load. If the ad fails to render within "X" ms (as per Paytm's standard threshold), it should be dropped and the next available ad in the funnel should be served immediately. Maintain standard security and compliance with privacy policies. For the <script></script> content that would come in the iframe tag outside the iframe body, on the native part, the privacy controls should be restricted.
Phase 2
In future phases, the iframe rendering support is expected to extend to below Widgets across Paytm.
JIRAs
Points open for HC
Requesting sample ad tags for various creative templates including 3D, video, in-banner video, etc. Need clarity on how HockeyCurve ensures security within their iframe—specifically, how they safeguard against malicious scripts or vulnerabilities (e.g. in PHP files in the src) that could potentially affect Paytm, such as app crashes or instability. How will Paytm receive logs or diagnostics for failure scenarios—such as iframe load failures, exceptions, or high render times due to partner-side issues? Clarification on how third-party click and impression trackers will be handled—will HC trigger these if the tracker links are shared alongside brand assets? Else, Paytm would require actual click and impression events for tracking consistency. What is the peak latency and requests per second (RPS) that HC’s infrastructure can handle under load? 
PRD - Ads <> Hockeycurve integration