Lille (7) [Avatar] Offline
#1
Hi,

After scanning TPJS Ch.1 and online search results for 'ad widget' and variations, I'm hoping to ascertain if there are any meaningful limitations, in practice, on the use of 'third-party javascript' -- as the authors intend that term -- for online advertising.

I feel like TPJS ads would be more ubiquitous than they are, absent limitations. Plus, I'm not convinced that the 'ad widget' examples I'm able to find are, in fact, interacting with TPJS ad provider servers. I'm thinking maybe there are de facto restrictions on HTTP method availability that limit the wider use of TPJS ads.

Next, TPJS Ch.1 seems to be describing a special business model for the involvement of TPJS widgets, where the opposite party wishes to enrich their site content with a widget -- from the chapter, for example, "Luckily, you've already found a publisher who's interested, and they've signed on to test-drive your widget" -- and not realize ad proceeds from it.

For context, my purpose in asking about this to better plan support for an API I've got coming out. It would be convenient for me to demonstrate a limited set of API behavior in the form of an TPJS widget that I would portray to potential customers as an ad template they can use. I just want to get comfortable that that's a fair use case to show or promise.

Hey, thanks for any comment and I hope this can somehow help with the final edition of the book.

Lille
benvinegar (68) [Avatar] Offline
#2
Re: is advertising use case legit?
Hey Lille,

Most ad widgets that you see use very little third-party JavaScript. Most of the time it's just a document.write call, which as we cover in the book (Chapter 2 + 3), has some negative performance characteristics.

There are certainly more advanced examples out there. For example, ad code that manages and coordinates multiple ads on the same page.

We don't cover that material explicitly, because we figured very few of our potential readers are implementing ad servers. We were hoping that the material covered would pass on some good practices for implementing one.

I apologize if this is a vague answer; I'm not 100% sure what you're asking. Perhaps if you have a more explicit question?

- Ben
Lille (7) [Avatar] Offline
#3
Re: is advertising use case legit?
Ben,

Thanks for your reply. Sorry that my question lacked some explicitness. Here's my attempt to sharpen it...

Basic Ad Widget Design: a few fields in a form that, once filled and submitted to the widget server, return some response to the viewer in the ad, e.g., 'Based on the information you've entered, you could be eligible for a X policy of $Y". Interaction with the ad does not necessarily open the advertiser's page (they may not even have one!)

Context 1: 'Take this ad widget and use it just as you would any of your online ads. Pay me for every successful user data submission with the ad.'

Context 2: 'Because of special restrictions on the functionality of ads like this, I have pre-arranged the use of this ad widget with a several online content sources relevant to your industry. If you would like to advertise on any of these sources with this ad widget, you will pay me for every successful user data submission with the ad.'

It seems to me like Context 2 is more probable, whereas I prefer Context 1, because if Context 1 is available then no special work is required in advance to find willing content 'partners' who agree to accept whatever special (Cross-Origin Resource Sharing) accommodation the widget requires.

Depending on your answer, I'll obtain TPJS and slap together a few IAB compliant ad widget templates and report back on my progress in a month or two.

Thanks,

Lille

Message was edited by:
Lille
benvinegar (68) [Avatar] Offline
#4
Re: is advertising use case legit?
Hi Lille,

That seems like a perfectly good use case – an embedded form that is distributed as a JavaScript snippet to web publishers. Have you taken a look at chapter 1? It's available free on the Manning web page, and I think mentions this use-case.

There's just one caveat – we don't cover the server-side components of these applications in any kind of depth, so if you're not familiar with those technologies, you might need some additional literature.

- Ben