I am a newbie in this space. I have a requirement to dynamically insert an ad and setup the infrastructure to monetize it.
From some basic search, I see that Google ad manager and AWS Elemental MediaTaylor are major players.
I am looking for any platform that is easy to implement and show immediate value.
Looking for some pointers.
(Apologize if I have posted in the wrong forum).
Off the bat, its worth keeping in mind that this space (i.e. the monetisation of 'Over The Top' content) is quite broad and can get technically deep very fast so some extensive research is recommended.
In terms of the two, you'll immediately notice that even though both offer dynamic ad insertions (DAI), both are not on the same level in terms of feature parity:
Google Ad Manager is an ad management platform for large publishers who have significant direct sales. Ad Manager provides granular controls and supports multiple ad exchanges and networks, including AdSense, Ad Exchange, third-party networks, and third-party exchanges.
Ad Manager is for you if you need:
A central place to monetize all of your inventory types (websites, mobile apps, videos, or games)
To manage a significant amount of ad revenue that comes through direct deals from buyers
To use third-party networks to compete for ad inventory
More complex reports to gain granular insights
https://support.google.com/admanager/answer/6022000?hl=en#:~:text=Google%20Ad%20Manager%20is%20an,%2C%20and%20third%2Dparty%20exchanges.
AWS Elemental MediaTailor is a channel assembly and personalized ad insertion service for video providers to create linear OTT (internet delivered) channels using existing video content and monetize those channels, or other live streams and VOD content, with personalized advertising.
https://aws.amazon.com/mediatailor/#:~:text=AWS%20Elemental%20MediaTailor%20is%20a,VOD%20content%2C%20with%20personalized%20advertising.
The above are key to keep in mind when establishing you present and future infrastructure requirements.
In terms of ease of implementation, since you mentioned being new to the space, both will require a learning curve when it comes to concepts / terminology as well as the respective content preparation + setup processes.
Perhaps consider reviewing the below resources to get an idea:
Getting started with Google Ad Manager’s Dynamic Ad Insertion : https://services.google.com/fh/files/misc/getting_started_with_dynamic_ad_insertion.pdf
Learn about Dynamic Ad Insertion (DAI) : https://support.google.com/admanager/answer/6147120?hl=en#zippy=%2Csee-how-the-dai-workflow-differs-from-traditional-video-ad-serving
Video on demand ad insertion with AWS Elemental MediaTailor : https://aws.amazon.com/blogs/media/video-on-demand-ad-insertion-with-aws-elemental-mediatailor/
How to implement reliable dynamic ad insertion using AWS Media Services : https://aws.amazon.com/blogs/media/how-to-implement-reliable-dynamic-ad-insertion-using-aws-media-services/
Related
i just arrived on this architecture, am doing a lot of research and i understood how it work in general but it's all theorical.
I decided to separate each step for the development of this architecture to start implementing so i can understand better these steps.
The first that i wanted to learn was the tenant provisioning, i wanted to apply it on AWS to mirror a production software example.
So, starting on that the common AWS service that i see most people using is AWS Cognito, but it's not clear in my mind the steps of the implementation, like how should i get the tenant data to onboard him in my app? Assuming it's tier based.
Should i have one database to store all tenants data separate from the application database?
I want to use microservices on this one because i think is better to onboard the tenant with different tiers and much more benefits.
Which AWS services should i use to make this process work? I'm not really asking about the implementation itself but a path to understand which services to use and how it connects with each other.
I hope i was clear about my doubts, english is not my mother tongue, sorry about that!
You are thinking in the right direction. However, there are decisions you need to make before diving into any saas service stack. I would start with
Planning my infrastructure - how many tenants/group.
the kind of tenant onboarding system you want
How will tenants onboard their users and manage authorization/authentication
Multitenant architecture, which needs to account for several things at the least like - DB model, shared vs isolated, data privacy, design keeping in mind industry data security standards
what will be your tenant deployment model. Remember one of the disadvantages of multitenancy is also slow time to market.
Your API stack needs to account for which apis needs to be multitenant and which are generic product offerings.
operational tool to monitor app health, client analytics.
how will you meter and bill the client and other non-functional decisions.
AWS offers good documentation to get started here : https://aws.amazon.com/blogs/apn/building-a-multi-tenant-saas-solution-using-aws-serverless-services/
I ask this question because I want to facilitate a workflow that utilizes a managed blockchain service such as the Azure or AWS blockchain service.
Is the true purpose attestations, provenance and interoperability?
In that aspect, aren't regular (legacy and or current) methodologies sufficient for data interoperability and the transfer and consumption of said data?
Lastly, if all this effectively is doing is creating a ledger account of data flow would a true advantage be the encryption of the data existing on the entire flow including up unto the edge?
If it cannot be encrypted up to the edge so that it is not readable at any point in time of the data flow into the data archive/traditional store is effectively worth any of the previous described gains of provenance and interoperability?
I think there is some nuance to this answer. The purpose of Azure Blockchain Service is to allow enterprises to build networks (consortiums) that enable the business workflows. The unique value that blockchain is adding to business workflows is a logical data model/flow with infrastructure shared to the participants (businesses). That is not easy to do with a traditional database model.
With regards to the encryption you mentioned above, the value with blockchain is providing a digital signature for every change in the system that is shared between enterprises. The typically is done at the client to provide the least chance for manipulation. Privacy, which can use encryption techniques, is something that can be used to allow participants to control access to change details. The fact that changes were made is still cryptographically verifiable, without sharing all the data details with everyone.
If you look at something like EDI that is done today with supply chains, this essentially is a complex network of enterprises, synchronizing databases. This typically suffers breakage of keeping all these things in sync. With a blockchain based system, the "syncing" is abstracted and the focus is more about the business logic, which is always cryptographically signed and verifiable. So it functions like a single "logical" data store, but is actually distributed.
I recently learned, traditionally, interbank payment systems need following features to carry out tasks:
need a central bank to prevent parties involved from going bust.
need a clearing house to perform netting algorithms to minimise liquidity requirement.
If we use corda to implement a similar payment system:
do we still need central banks and clearing houses appearing in the networks as independent nodes?
If so, what do they do?
Do they serve as notary nodes or something else?
What relationships do they have with commercial banks?
Why this kind of corda-based design is better than traditional interbank payment system?
Corda has been used to develop a real-time gross settlement pilot in association with the Monetary Authority of Singapore. See the report here: http://www.mas.gov.sg/~/media/ProjectUbin/Project%20Ubin%20Phase%202%20Reimagining%20RTGS.pdf and the source code here: https://github.com/project-ubin/ubin-corda.
Using Corda removes the need for clearing houses. Netting and delivery-versus-payment/atomic asset swaps can be achieved without the need for a centralised party. Corda also removes the need for reconciliation, which happens automatically via the platform.
More importantly, Corda is driving towards a vision of global interoperability. See
https://medium.com/corda/universal-interoperability-why-enterprise-blockchain-applications-should-be-deployed-to-shared-3d4daff97754. In this vision, assets are not trapped in silos, and can move freely across the network. For example:
BankNode receives cash via the interbank payment system
BankNode lends this money to SupplierNode in exchange for an obligation
SupplierNode uses this money to purchase goods from FactoryNode
FactoryNode uses the money to pay the suppliers of its raw materials
And so on, and so on...
Coordinating things using a clearing house remains possible when looking at a single area like interbank payments. However, as the network grows to support many different business use-cases - supply chain, lending, assets, payments... - it becomes increasingly difficult to find a coordinating party that can be trusted by all parties, across industries and regions. Corda removes the need to identify such a coordinating party.
In this vision, central banks are likely to continue to exist as trusted issuers of fiat currency.
This conceptual question has crept into my mind after becoming more familiar with AWS. In general, I’m curious if there is a best-practice and/or convention as to when an API provider should group endpoints into a new, separate API (vs. lumping the endpoints into an existing API).
To illustrate, let’s say a Service creates digital wallet coupons on behalf of Manufacturers, to be redeemed by Consumers at a bunch of Mom & pop stores — some of the activities the Service might engage in include:
Receiving data from the Manufacturers (in order to build the digital coupons)
Providing a mechanism for Consumers to find and download coupons
Providing a way for the Mom & pop stores’ payment terminals to validate the coupons
And, oh by the way, the Service might also be required to ...
Implement a variety of endpoints, based on technologies involved (e.g., PassKit with Apple Wallet)
So?
With AWS, it’s easy to modularize one’s backend (e.g., have an RDS instance for the database, run a few lambda functions for microservices, etc.) and load balance it all. API Gateway adds to this in that each endpoint can point to different things (lambda functions, EC2 instances via HTTP proxy, etc.).
Consequently, one approach might be to define one API in AWS API Gateway and have all the endpoints underneath it:
API: “Master”
/coupon
POST = create a new one (for Manufacturers)
PUT = update an existing one (for Manufacturers)
GET = retrieve one (for Consumers)
/coupon/validate
POST = verify it’s still valid (Mom & Pop store use-case)
/apple-wallet
/{version}
/passes
... per documentation
/devices
... per documentation
But would it make more sense for the Service to shave off the /apple-wallet endpoint and create an entirely new, separate API?
Alternatively, if the Service was going to publish documentation for public developers to use, would it make sense to move the Manufacturer-relevant endpoints into a separate API altogether?
Since AWS makes the effort of splitting endpoints so simple via API Gateway, are there any standard practices for when you should (or should not)?
Thank you for any insights / opinions!
My two cents. Think about your end-user for your APIs. You will have different developer end-users for each API set.
Your ideal situation will have each developer end-user only seeing the APIs that are relevant to them. So you should split your APIs into different Gateways according to the end-users
In the theoretical situation you describe:
Create an API for Manufacturers so they can integrate with you to create coupons. If you do the integration internally it will be the corporate sales and presales people who talk to the manufacturers
The users for the Service and End User coupons might end up being the
same app developers that create an interface for both stores and
users. So create a coupon API for them
Separating both should also give you security benefits as you will protect the knowledge of your Manufacturer API from the users who might try to hack it
I'm searching for a reliable trading company which exposes a web service for live trade.
Basically I'm interested in:
opening an account (you know, minimum everything for a start - minimum account value
for opening, minimum commissions, etc.) and getting credentials.
Through the web service, provide my credentials and connecting to the server.
Through the web service executing trade operations (mainly buy/sell level 1 stocks under
NASDAQ/NYSE).
Does anyone familiar with such a service and can recommend it?
Cheers
There are a bunch of online brokers that meet the criteria you shared in your comment. An example of a widely used API by retail traders is Interactive Brokers. You can also take a look at Trading Technologies which is more sophisticated in my opinion and have better support. Then there is also TD AmeriTrade. You can also use standard market protocols like FIX to write an execution connector through a FIX Engine. Many brokers support FIX, an example is Goldman Sach's electronic trading platform.
Secondly, from your comment it seems like you are sort of in the testing phase. I encourage you to take a look at some retail trading platforms that are not brokers perse, but allow you to connect to multiple brokers and data feeds. Take a look at NinjaTrader, OpenQuant to name a couple.