[docs-infra] Fallback docs inline ads to an in-house ad

[alexfauquette]

Fix #39272

[mui-bot]

Netlify deploy preview

https://deploy-preview-39285--material-ui.netlify.app/

Bundle size report

No bundle size changes (Toolpad)
No bundle size changes

Generated by 🚫 dangerJS against ee411a3

[danilo-leal]

Can't necessarily judge the code quality per se, but it looks good!

But... I do want to ask if that's really what we want to do? Like, every time visitors open a code block, an ad appears, which, from a business perspective, is totally understandable, but from a docs UX one, is super annoying. It fills the page with ads (the one that's fixed on the top of the page + all of these new ones on the code blocks + sponsors). How are we feeling about it? Is there a middle ground where we can balance these two aspects?

cc @oliviertassinari

[alexfauquette]

It fills the page with ads (the one that's fixed on the top of the page + all of these new ones on the code blocks + sponsors)

Just my two cents:

1. We might over-emphasis how it impacts readers. I've some friends that were surprised when I say that one source of revenue is ads. On the same topic: those white spaces have been here for a long time and nobody paid attention, I guess because when you open code, you're immediately focused on the code
2. It is not a change in terms of layout since it is just a fallback for when carbonAds has no ad to display.

But we can question the value of those internal ad. Do they bring traffic/sells?

[danilo-leal]

those white spaces have been here for a long time and nobody paid attention

Well, it's much easier to not pay attention to empty space than it is to an ad 😄

But, just as a clarifying question, as I know that the ad on the top of the page doesn't run in these deploy preview links — would the behavior of these inline ads change in production? Asking because you mentioned it being "a fallback". So, if it's not going to be displayed every single time I uncollapse a code block, that sounds better!

[alexfauquette]

To clarify, previously:

1. You expand the code
2. We call advertiser
3. option a. they have an ad -> we display it
   option b. they don't have ad -> we place an empty box

The empty box does not collapse when closing the code preview, to have the same behavior as the ad which is not removed when closing the code example

With this fix, everything stays the same except that "an empty box" is replaced by "an inhouse ad"

So, if it's not going to be displayed every single time I uncollapse a code block, that sounds better!

For curiosity, I expanded the first 10 demos in button docs only one of the ten did not display an ad.

[danilo-leal]

Gotcha, that makes sense! I was referring to the deploy preview when I mentioned that it is being opened every time (check the video below)... but, if that's not how it will play out in prod due to this logic, I'm on board! My only concern is the docs getting very polluted by ads everywhere (top-level ad block; diamond sponsor; inline code block ad).

Screen.Recording.2023-10-09.at.14.16.46.mov

[danilo-leal]

@alexfauquette Just circling back on this one to see if we're missing anything or if there are any pending questions?

[alexfauquette]

@danilo-leal No technical pending issue. Just a product decision about are we ok to display internal ads when carbon call fails

[danilo-leal]

Gotcha! My 2 cents is that it's an alright change as long as it doesn't appear on every single demo as shown in the video above 😬 Not sure if that's a deploy preview thing only or if prod would also behave like that. Is it possible to confirm?

[alexfauquette]

Since it's not urgent, we could go that way:

1. update the GA event manager to distinguish the different kinds of ads (banner, inline)x(internal ad, carbons ad)
2. wait to get stats
3. take an informed decision that could be
   • don't show internal inline ad
   • do not always show the ad below the demo with some random sample
   • always show the ad below the demo

[danilo-leal]

I like this approach! But would it be possible to understand, through GA, whether the inline ad is being shown on every demo upon code block expansion? Or like, not in opposition to this GA plan, is there a way to understand why the deploy preview is behaving this way?

[oliviertassinari]

Feedback on the code:

1. It looks like call: ad.call, does nothing, we can remove it.
2. There is a legacy reference to inline2 that we can remove, dead code. In the past, I tried all the possible ad placements and ad shapes on the docs, I kept the most effective one, it was at a time when it was one of the main revenue sources.
3. The code organization looks confusing. We render a component that is called AdCarbonInline but who can render in-house ads. I think that we should move the AdCarbonInline component inside a new AddInline file and rename the component to AddInline. It would make more sense. The main constraint for ads is how we show them, and second, if it's CPM (Cost per mil) or CPC (Cost per click) ads.

But, just as a clarifying question, as I know that the ad on the top of the page doesn't run in these deploy preview links — would the behavior of these inline ads change in production?

@danilo-leal Ads are only disabled in local development. They run in the deploy preview. If you don't see them, I believe it's either that you have an ad blocker or you are looking at the ad below the code which might not serve content (depending on location & advertisers' availability).

update the GA event manager to distinguish the different kinds of ads (banner, inline)x(internal ad, carbons ad)

@alexfauquette Arf, it does look like the analytics that I added in the past are now a bit all over the place, I see a few things that I broke after a couple of refactorizations 😅.

---

In terms of next steps, I think we could:

1. Fix the GA events.
2. Release this. I would be curious to see the impact of the changes in this PR. Does it correlate to any meaningful revenue? How many extra clicks/impressions does it generate? Carbon tells us the revenue that the ad below the code brings, it's in the order of 20%.
3. I think it would be fair to include the diamond sponsors in inHouseAds, as long as we can reuse the same information as we use in the rest of the docs, (same images, description, etc.). GA tags would be: data-ga-event-category="sponsor" data-ga-event-action="docs-code-ad" data-ga-event-label="doit.com"

Then, In a few months, based on 2:

a. If it's high impressions or low revenue or no real traffic for diamond sponsors: revert. Instead, we could simply remove the gap when there is no carbon ads.
b. Otherwise keep it.

---

Longer-term, there is a strategic reflection to have on what's the perception of open-source projects by developers with ads. As far as I can push it, I don't feel there is any real correlations, however, I can observe a trend where the best open-source projects don't have ads. So It feels like removing ads is the overall direction to take. Hence outcome a. feels more likely.

I think that once ad revenue is less than 1% of the company revenues (I don't know for sure, but today, we might be at 2%), we could remove all the ads. The only reason to keep ads would be

1. to incentivize a paid plan that doesn't have them, a bit like what Twitter is doing (but they don't even remove all the ads, #WUT) 😄. One thing that I would love to have today is allowing MUI X customers to remove ads from the docs, it feels unfair for them.
2. to try to keep the open-source sustained without commercial code (this feels worse from the perspective of a user)

but It feels best to give up on these two. So once we hit <1% of revenue, let's kill the ads (meaning other sources outgrow ads, not in the sense that we are less effective with ads 😄). I suspect we will be at that point in Q4 of 2024. Proposal added to https://www.notion.so/mui-org/Remove-ad-in-the-docs-918c03b0eaaf4c67b9b2a863591a2e3a