B2B Stack

b2bstack

Bystack — Blockchain as a Service Platform (BaaS)

No one likes ads. Where’s the lie? According to Kantar Millward Brown's AdReaction: Engaging Gen X, Y, and Z study, almost 70% of Gen Z (and Millennials) use ad-blocking software. Growing up with constant advertising buzz has made them all the more impervious to it. Since they prefer being online and playing video games over anything else, it's no surprise they are hard for marketers to reach. Avoiding traditional advertising doesn't mean that they avoiding branded content. The trick is to understand their world and enter it on their terms. Content is king Deloitte's 2021 Digital Media Trends survey has shown that watching TV has dropped to fifth place as Gen Z's favourite way of spending free time. Video games, Internet browsing, social media posting and hanging out online have knocked it off the pedestal. Graphic 1 shows an infographic on Deloitte’s 2021 Digital Media Trends survey Younger audiences grew up in an interactive world, where engagement and interaction are the norm. Television is too one-sided for them - you can't comment on anything, and there is no discussion or joking around. You're simply on the receiving end of a transmission, which is no longer enough. The world of television is distant, fake, and doesn't reflect their everyday experiences. Content creators and influencers using platforms such as TikTok, Instagram, Twitch, or YouTube deliver the type of entertainment TV could never hope to replicate. Entertaining and interactive content co-created with audiences is the base for influencers to create close bonds with their followers, directly translating into reach and high CTRs. Honesty goes a long way Generation Z has more of an aversion to insincerity and inauthenticity. Anything that induces instant can turn the audience against you. They will spot them real quick. cringe For example, if your brand has nothing to do with gaming, don't expect a 'for gamers' sticker to be enough. Don't try to turn your brand into something it's not. Take , run by inStreamly and co-created with VMLY&R. Danone's streaming-oriented campaign Danio didn't try to convince everyone they are a gamer-oriented product by changing the packaging into a pixelated neon pink and purple vomit. They communicated with gamers in their language and related to them while staying true to the brand. Don't be like a used car salesman If you want to promote your brand through content creators, try to seek out the ones whose content fits your brand persona and start from there. You would be surprised how much the audience will appreciate you supporting their favourite creator. An influencer is a charismatic character that their channel and community revolve around. People follow and trust them on an almost personal level, so when planning your influencer marketing campaign, always keep in mind what the public perception of your brand is. Being too pushy and direct with your messaging can irritate and antagonise your target audience. Viewers are LIVE, join them! Boosted by COVID pandemic lockdowns, the number of stream viewers reached unimaginable levels. In 2020 we saw an 80% increase in hours watched. Even the biggest optimists predicted this trend to drop rapidly during 2021. However, in reality, we have seen another 21% growth. Graphic 2 shows a graph on the live stream watch time against time What does it mean? Viewers who started watching live streams during lockdowns enjoyed it so much that they stuck around. As we have seen repeatedly, the best Gen Z marketing campaigns are the ones that blend sponsored content with entertainment. Live broadcasts have the potential of making your branded content a conversation piece or even the central theme for the stream. Non-intrusive content, eye-catching animations, or displays that react to in-game events are fantastic ways to turn viewers into engaged customers. Mixing and matching creates an exciting experience everyone can enjoy. These multi-layered interactions were at the core of one of the most successful streaming marketing campaigns of 2021. New tech is your friend Gen Z lives and breathes technology. Innovations are expanding the possibilities for your content to reach your target audience. TikTok, Instagram, and Twitch are fantastic for producing content that's entertaining, fun, and educating for the viewer. Ever seen the Duolingo Tik Tok channel? Brands can use new marketing tools such as inStreamly, Bidstack, and Destream to become more innovative and visible. Brands willing to understand the new generation and enter their world on their terms will stay ahead of the curve for years to come. About inStreamly Thanks to the sponsorship campaign model, allows marketers to reach gaming audiences in an organic, non-intrusive way. inStreamly Automatically display engaging branded artworks across thousands of gaming live streams. The streamers’ viewers will appreciate your support.

5 Things You Should Start Doing to Reach Younger Audiences

Most of the web apps I build eventually end up needing a background worker. There will be some slow or heavy task that really should run independently, like an integration with a third-party server, a web scraper, PDF creation, something. The app at this point crosses a barrier, it now has a multi-service architecture. There's a new layer of complexity to manage. Containerization and the growing popularity of microservices has produced a fantastically rich ecosystem of tools to support multi-service architectures. Most are intended for large dev teams and heavy user loads, but can a small team benefit too? When is the complexity and overhead of such an architecture appropriate? How far to take it? And how do you actually implement it? I've been playing around with some ideas, trying to answer these question, looking to find a sweet spot for the smallish team of ~ 2-20 developers, something that works nicely with an existing Django/Laravel/Node/Rails framework, that picks up the main advantages without adding too much of a burden. I've shared my rough pass at a sample solution, described below, but let's first look at the factors a small team might consider when evaluating a partial/hybrid microservices-based architecture. webstack-micro A small-team perspective In a small team, we don't feel pressured to break up our code base into separate services, where a large dev team might (nicely described ). Going pure micro adds layers of overhead and pain that a small team doesn't need to pay. by Shopify What would have been a simple database transaction or join turns into something much harder, requiring interactions between multiple services and possibly two-phase commits. Since we don't want to split our app into separate micro services, let's define a "microservices architecture" to mean something more general: containerized services running behind a gateway/load balancer/Ingress controller with some form of centralized authentication. Ok, defined, so now we can call it "microservices" and not just "Docker", but why would we want it? A Touch of Good Service With a microservices architecture in place, it's quite easy to add little services that compliment your main app. If you need to do web scraping, perhaps you'll decide to add a service with headless chrome, coding it in JavaScript rather than in PHP/Python/Ruby on a library originally intended for functional testing. Once the microservices plumbing is in place, adding any single new service is a breeze. You might not want to introduce too many different languages to your project, but Docker Hub is brimming with useful services that don't require custom code. Does your app need optical character recognition? You can drop in a best-in-class OCR service. With centralized authentication already in place, you can expose it as an independent API endpoint too, should that make more sense than using it as a background worker, it's up to you. Rich background workers Background workers drove us to this, we may as well get them right. When a worker finishes, let's push the results to the user over WebSockets. Our new plumbing supports that too. A heavy-duty message broker like RabbitMQ won't be suitable for every project, but it fits in nicely if needed. A good infrastructure guides future decisions. I once had to integrate a Rails app with an awful ERP system. None of the third-party Ruby libraries worked. The library provided by the vendor worked but was in a different language. Even ignoring the deployment issue, our Ruby-based background system wouldn't work in that environment. Adding a new message broker was just too much to consider at the time, so I went with something hacky and restrictive instead, recording the requests from my local system, converting them to string templates that our app would send. Room to grow After paying the initial complexity cost of a microservices architecture, other benefits are within close reach. If some users are making abusive API calls, imposing rate limits in the API gateway isn't a big step. Or maybe you'll configure the gateway to support canary releases, where you can try out a scary change on a small portion of your audience before rolling it out to everyone. (And have it automatically revert if it encounters new errors.) Although heavy user load might not be a primary consideration for many smallish teams, the benefit of auto-scaling is nothing to sneeze at. Even with gently increasing load, some feature or service will likely outpace the others in resource consumption. Being able to scale them separately is pretty nice. At what cost? Let's look at the downsides... Resource heavy Running numerous containerized services eats up memory and CPU. When I limit Docker to 2 CPU cores on my development system, the webstack-micro example project (below) feels pretty slow, especially on start. The example runs only 9 relatively light services--a larger app would be painful under this allocation. There's a good chance you'll need a modern, hefty dev system. If you're using Java or .NET or have a whole lot of different services, the project might overwhelm a typical dev laptop. If you reach that point, you might need to shift dev mode to the cloud, requiring always-online access (plus a payment if using a commercial service like Okteto), or need to write scripts that skip or stub services, another payment in complexity. This downside mainly refers to dev mode--it doesn't necessarily predict higher hosting costs but that is a possibility. Living in containers Overall, the local dev environment feels a lot like any project that uses a virtual machine for dev mode (like Vagrant projects.) It shares the same downsides: you need to set up remote debugging to step through code; there's an extra step to run commands inside the vm/container and they run more slowly. Learning curves If you're introducing new technologies to your project, at least one person will need to learn each one. In particular: Docker Compose, the API Gateway (eg Traefik), and probably Kubernetes. Depending on the services you decide to include in your project and the composition of your team, you might be introducing other learning curves, such as RabbitMQ, Redis, WebSockets, etc. Plus, you'll be changing the deployment process. In a previous startup, we eventually put in place fancy devops features like hot deploys and no single-points of failure, but it required a lot of effort and a pile of vendor-specific scripts. Containerization makes features like these much easier to achieve (and has the benefit of being fairly portable across hosting providers) but you still have the upfront cost of putting something in place and learning how it all works. Alternatives Rather than adopting a microservices-like architecture, you can avoid or defer it in various ways, depending on what pain point your project is hitting. Instead of using background workers, you might offload such tasks to a hosted service like Serverless or AWS Lambda. Similarly, many data centers offer managed solutions, not just for database persistence, but for services like RabbitMQ. You can also find separate, commercial services for WebSockets and authentication too. Of course, you can also go in the opposite direction, running servers that do whatever you need, with or without an API gateway, with or without containerization, with or without monitoring. Example setup: webstack-micro If you decide the flexibility and cool features of a microservices architecture are worth its drawbacks, try dropping your app into to kick the tires. (Free / MIT license.) webstack-micro I used as a playground, trying to find a balance between functionality and complexity that might be appropriate for relatively small teams. webstack-micro It sets up Traefik as its API Gateway/Ingress controller. Traefik interacts with one of the example services to enforce centralized authentication for any route marked as protected, requiring either user login or a JWT token. The example also includes the plumbing for background-push, with example uses of background workers sending results over WebSockets. All of the microservices-related examples I've evaluated would not help a small team get started. They completely ignore authentication, the hardest part to all this, and seem to have very large projects in mind (like .) Google's example I hope the example gives some teams a big boost. webstack-micro Artwork credit: https://unsplash.com/photos/ECjHeJtRznQ https://unsplash.com/photos/afq5-t0ZGtQ https://unsplash.com/photos/ZihPQeQR2wM https://unsplash.com/photos/j_Ckc_r25zc

Stories, News & Mentions about B2BSTACK

B2bstack’s Stories on HackerNoon