Why the city's vision never fades: An engineer talks about the excitement of DOOH development

When you hear about ad delivery development, many people might think of the Web world.

At Geniee's ad delivery development team, we handle DOOH in addition to Web ads, which offers a wide range of excitement.

DOOH is a product that delivers advertisements to large screens in the city and signage inside stores. In offline advertising experiences, the required specifications, the difficulty of development, and the tangible feel of the work are all different.
Moreover, in DOOH, there are times when you handle everything from the delivery infrastructure and terminals to the management screen and applications within a single product. That is precisely why your development scope and perspective as an engineer continue to expand.

This time, we spoke with Mr. Komiyama, General Manager of the Demand-Side Development Department, and Mr. Iwai from the same department, about the breadth, excitement, and difficulty of demand-side development at Geniee.

An almighty group that builds three products in one department

—First of all, could you tell us about the characteristics of the products handled by the Demand-Side Development Department?

Mr. Komiyama:
Even though we call it the demand side, we build three products in one department. The domains we handle share a commonality in terms of "ad delivery," but the nature of each product is significantly different.
There are areas focused on the Web and e-commerce sites, and there are areas like DOOH that face outdoor advertising and signage.
Even within the same ad delivery platform, what we prioritize differs quite a bit.

—Specifically, how are they different?
Mr. Iwai:
For example, with Web ads, it is important to know how to handle high traffic. We are required to handle a massive amount of traffic, such as 100,000 requests per second, so we prioritize processing speed and the like.

On the other hand, while the delivery mechanism is of course important for DOOH, the weight of "ensuring it is displayed at the targeted time and in the targeted place" is even greater.
If a large screen in the city suddenly goes completely dark, it is a major problem for the users (people walking in the city) as well as for both the advertisers and the media companies.

Therefore, it is not just about simple delivery load countermeasures; the design and operation to "ensure it is delivered at that time" become extremely important.

DOOH doesn't end with just "delivering"

—From a development perspective, what kind of difference does "ensuring delivery" make?

Mr. Iwai:
A simple DOOH mechanism is like the image shown; it passes through various platforms before the ad content set by the operator is actually projected onto the display.

You need the mindset of guaranteeing that the set video or image is definitely displayed on the screen.
To that end, we design it to start downloading a little before the broadcast time, and we think about how much leeway to provide while looking at the network environment, material size, and duration.

—So even with the same ad delivery, the required design philosophy is different.

Mr. Komiyama:
That's right.
On the Web, there are many situations where optimization and speed right up to the moment of display are emphasized, but in DOOH, it is important whether it is "in a state where it can actually be played on the display."

In daily life, I think it's common for ads to stop on smartphones or PCs if the network is weak, but if the same thing happens with DOOH, it has a major impact on advertisers, viewers, and media companies alike.
Since we need to optimize everything, including comparing terminals, installation environments, and communication protocols, to make the broadcast perfectly successful, the prerequisites and important perspectives are completely different.

A wide range of areas to touch within a single product

—Where does the unique excitement of DOOH development lie?

Mr. Komiyama:
It's that the technical area you touch within a single product is quite broad.
In DOOH, there are terminals for broadcasting, and sometimes we coordinate with those terminals using proprietary specifications, and there is also the Web management screen. There are delivery servers. We use the cloud, and we also have on-premise delivery servers.
While there are devices widely used as DOOH broadcasting equipment, there are also cases where broadcasting is done via Android apps.

In other words, even if we call it one product, in reality, various elements are connected, and it won't be completed unless you think about that coordination.
This might be closer to the feeling of "going to look at everything necessary to deliver a single value," rather than just Web or just server.
I think that is a very interesting part as an engineer.

Our work remains in the city's landscape

—Is there any excitement other than the technical side?

Mr. Iwai:
Of course there is.
Personally, being involved in the landscape is a big deal.
If it's a large screen, it becomes part of the city's landscape, and if it's in-store signage, it becomes part of the store's interior. Being able to walk through the city and think, "Ah! That's an ad I worked on!" is also a sense of achievement (laughs).

Involved in everything about ad delivery

—Are there any other characteristics of DOOH development?

Mr. Iwai:
I think it is characteristic that we face both the advertiser side (demand side) and the ad display side (supply side) elements = "being involved in everything about ad delivery."
For example, managing the screens is also one of our tasks.

There is also a mechanism that automatically sends a notification to check "if this screen is working normally" if there is a broadcast schedule but no access from the terminal.
There is a management screen for entering and setting up projects, and we also need to look at the status of the terminals that are actually broadcasting. I think the excitement of DOOH is that even if you are developing in the context of the demand side, your perspective reaches as far as actual operations.

Expanding the domain, organizing the structure, and further strengthening the product

—What would you like to work on in future DOOH development?

Komiyama-san:
In the short term, I would like to simplify the architecture a bit more.
Since we manage a variety of things, there are parts that are connected in complex ways, so I want to untangle the structure a bit. Doing so should make development and improvements easier.

Another goal is to expand the team's technical scope.
Up until now, we have been operating with a small number of people, so there are some differences in the areas each person understands. That is precisely why I want to expand the 'areas of understanding' and 'areas of capability' within the team moving forward.

—What kind of people would you like to see join the team?

Iwai-san:
Android expertise, in particular, is an area we want to further strengthen.
In DOOH, multiple layers—Android, Web, delivery infrastructure, and device integration—are connected, so if someone who can bring strengths in those areas joins us, I think the things we can do as a team will expand significantly.

Komiyama-san:
If you can start from one area of expertise and broaden your perspective to the entire product, this environment should be quite interesting.
Also, as I mentioned at the beginning, my team develops various ad delivery platforms in addition to DOOH.
If there is anyone who wants to broaden their scope across frontend, backend, infrastructure, and more, I would love to talk with you.

Listening to the story of DOOH development, it was clear that this is not just about ad delivery.
It is about crossing multiple domains—Android, Web, delivery servers, and management screens—to ensure the reliability of ad delivery in the city.
Geniee's DOOH development, while within the framework of advertising, covers a wide range of areas.
That is precisely why it should be a great challenge for engineers who want to deepen their expertise in one area while stepping into the product as a whole.