63 results found for ""

  • Radio Days Africa 2020: Session with Jonathan Lumley

    We are excited to contribute once again to Radio Days Africa, the largest radio conference in Africa. With the usual format of a 3-day conference in Johannesburg now impossible, Radio Days Africa pivoted to hosting 20 engaging sessions over 20 days. "From interactive chats, panel discussions, master classes and individual presentations, #RDA2020 aims to promote sector wide learning and keep the radio industry talking (to and about each other)" - This year, Jonathan Lumley shared his thoughts in a session on the 'Top Promotions from Across the Globe' which you can watch on-demand:

  • Record and publish your audio content in real time!

    Use Fabrik to capture live radio content and immediately publish as a podcast or download a snippet of archived audio from any time in the past! Fabrik's Echocast application is an audio recording and publishing tool built for the live radio environment. The application is browser-based, making it accessible via any secure desktop computer or mobile device and, due to its cloud-based technology, processes and shares your audio within seconds. For many of our Fabrik operators, the real-time audio recording and podcasting capabilities found within the Echocast application have become an invaluable contribution to your daily workflows, allowing podcasts to be easily recorded and published in real time to your website and/or mobile app. Within Echocast, you are empowered with the following audio recording and packaging capabilities: Record real-time audio from your Live stream Echocast's most distinguishing feature is the ability to record your radio broadcast in real time from your live stream, and publish the clip as a podcast - seconds after the live on-air moment occurs. To access this feature, simply tap the button in the top-left of the screen labelled 'Start Recording,' where you'll be able to record in real time, pause and resume for ad breaks, and add searchable metadata to your new podcast right before publishing. Tag your content to make it more discoverable Within Echocast, you have the ability to tag and add metadata to your podcasts to make it easier for your audience to search and find. Go to the menu in the top-right of the screen to create Categories - which are similar to organisational ‘folders’ for grouping together related podcasts. Categories are typically created for regular features, news bulletins, and even regular shows eg. ‘Prank Call’, ‘News’ or ‘Breakfast’. Grouping recordings into Categories eases content discovery for your audience. Presets facilitate one-click recording, saving and publishing to further simplify and streamline the workflow of recording frequent/regular features. Access the Presets section at the top-right of the screen. When configuring a preset, you would add the metadata, category and other settings that all podcasts with this preset would need to have, eliminating the need for this to be entered every time. Good examples are ‘News’ and ‘Sport’, but presets can also be created for any regular programming feature. Create a featured podcast When you set your podcast as 'Featured,' it will be published right at the top of the Rewind section in your app or web page - as the very first podcast your listener sees. This is particularly useful if you're running an advertising campaign, or would like to elevate a certain podcast in your app or website. Upload existing audio File If you have an existing piece of audio you'd like to publish as a podcast to your app or website, upload it via Echocast, add metadata and publish! Download archived audio from any time in the past Echocast offers you the ability to download an audio clip from your archive, to play again on-air or even send to an advertiser for your post-campaign analysis. All you have to do is tap the 'Request Audio Archive' button, specify the exact time of the audio you'd like to extract, which will then be emailed to you within minutes.

  • Get closer to your audience with Metrics!

    Use key insights from Fabrik's Metrics application to track live engagement and audience behaviour over time. If you're already a Fabrik client, you may have had the opportunity to start using the platform's newest application, Metrics - a real-time data visualisation and tool which offers a glimpse into your live audience engagement as well as key insights about your audience's behaviour over time. Having access to this kind of information empowers your teams to make strategic decisions in real-time by gauging how your audience is responding to your content and programming. Here are some examples of the kind of data and information that is now available to you via Metrics and, as the application evolves, our aim is to add even more insights related to audio engagement, as well as information around advertising inventory to strengthen your offering to advertisers. Current app and Live-stream Engagement View a summary of particularly useful live data, such as chat messages sent within the last hour, new member registrations and listeners accessing the live stream from your app or Fabrik-powered live-stream web widgets right now. Live-Streaming from your Fabrik and icecast streams A consolidated view of all streaming numbers from your Fabrik and Icecast streams. View the graph with trendlines to spot trends over time. App Engagement and downloads over time It may also be useful for you to track the impact of campaigns or on-air calls-to-action by monitoring app engagement or app downloads over time. App Engagement View a summary of your app engagement over time, including: Total app visits - the amount of times the app was accessed within the chosen period. Unique visitors - the number of discrete individuals who accessed your app within the chosen period. Unique registered visitors - the number of discrete individuals who have registered a profile within your app within the chosen period. App Downloads It's also useful to know how many times your app has been downloaded on each platform - in total, or within a specified period. Billboard Advertising If you are taking advantage of some of the advertising and revenue generating aspects of Fabrik such as billboards, then head over to Metrics to view all of your billboard campaigns in once centralised space, with billboard Views and Clicks visible at a glance.

  • Optimising the future of Fabrik's apps

    Modernising our native Android and iOS codebases by migrating to Kotlin and Swift. As developers contributing to and maintaining the Android and iOS mobile apps that make up immedia’s Fabrik platform, there are a number of things we expect to happen during the lifespan of the mobile apps we deliver. Bugs will arise, new features will need to be ideated, and both Apple and Google will release major updates to their operating systems - to which our apps will be required to adapt. At each of these junctures, we’ll need to respond quickly as, of high importance to ourselves and our clients, is the guarantee that as environmental challenges evolve, so do our mobile apps to meet these challenges. At a high level, there are 4 areas of coding support that Fabrik apps receive: Corrective, better known as bug fixing. Adaptive; adapting to the latest hardware and OS changes. Perfective; dealing with changes in user requirements. Preventative; code restructuring & optimisations aimed at reducing complexity and preventing future errors. The first three areas are fairly self-explanatory and commonly practiced as our team works hard to ship regular app updates for our Fabrik clients with the latest bug fixes and improvements, additional feature enhancements and finally, updates required to become compliant with the latest OSes. However, as developers, we don’t readily reveal the ‘preventative’ part of what we do i.e. the behind-the-scenes code improvements, re-writes and optimisations that are implemented on an ongoing basis. In this blog post, we offer some insight into what that looks like for Fabrik in particular, and how we’re working to ensure the longevity of our product through modernising our mobile app codebases. When immedia’s development teams started to build Fabrik’s Android and iOS apps, the Objective-C coding language was initially used on iOS whereas Java was used on Android. Since then, alternatives from Apple (Swift for iOS) and Google (Kotlin for Android) have matured and become the gold standard for developing apps on their platforms. Now, any new app developer just starting out will default to using one of these newer languages rather than the 36-year old Objective-C or 20-year old Java. Swift is one of the fastest growing languages in history and, in 2019, Kotlin became Google’s preferred choice for Android development. One of the key benefits of these languages is that they can be used in conjunction with their predecessors. On Fabrik, the code is currently a combination of the old and the new, and our endeavour now is to future-proof our source code as much as we can and systematically re-create as much code as possible into Swift and Kotlin. However, for some features this interoperability does take some effort, so in order for us to keep delivering new features and app enhancements in the future, we’ll need to allocate time now to preventative maintenance with an expanded effort around code rewrites and optimisations. We will move quickly to ease out the historical languages in favour of the modern counterparts, so that our platform will continue to be operational today and for years to come. When we end this journey, our apps will be more efficient and less error-prone, which will make our investment of time and effort into these code migrations worthwhile. For the most part, Swift and Kotlin share the same ideologies and will deliver much of the same benefits on their respective platforms. Here are a few key points on why we’ve chosen to make these transitions: 1. Speed The new languages are fast; for example, a simple search algorithm has been benchmarked as being 2.6 times faster in Swift than Objective-C. Historically Objective-C has never been a fast language. It’s been built as an after-thought on top of the C programming language. Which means it carries with it legacy C functions. Swift has removed the limitations of the C language. Further, Objective-C also uses runtime code compilation rather than compile time: this means that when an Objective-C object calls code in another object, it’s not a direct function call; rather it leverages message passing. The runtime determines if an object actually implements the function represented in the message. If it doesn't implement it, the class will either forward the message onto another object, or throw an exception. This is incredibly fast, but still adds an overhead which would be measurable when it happens millions of times. Swift and Kotlin benchmarks continue to improve with each update of the language. This is a key factor as it’s important to stay up-to-date with the latest releases of the language in order to reap all of the benefits. Swift currently is in version 5.2 with Kotlin at 1.4. (languages also receive updates with additional capabilities, bug fixes and improved methods of performing tasks). 2. Better Syntax The languages are lean, intuitive, easier to read and it’s more efficient to apply changes when needed. Kotlin has removed a lot of clutter and redundancy from code. Literally a class that used to be 100 lines is now only 2 lines. This aids in preventing common programming mistakes (resulting in far fewer crashes!) as the more code you have, the more it costs to maintain due to the additional overhead it brings. An example of a Kotlin feature that helps to reduce the size of the code base are Data Classes which allows the expression of POJOs with minimal code. The following showcases the original code in Java versus the Kotlin implementation. Java Class: public class Person {     private String name;     private String surname;     private String id;     public String getName() {         return name;     }     public void setName(String name) { = name;     }     public String getSurname() {         return surname;     }     public void setSurname(String surname) { this.surname = surname;     }     public String getId() {         return id;     }     public void setId(String id) { = id;     }     @Override public boolean equals(Object o) {         if (this == o) return true;         if (o == null || getClass() != o.getClass()) return false;         Person person = (Person) o;         if (name != null ? !name.equals( : != null) return false;         if (surname != null ? !surname.equals(person.surname) : person.surname != null)             return false;         return id != null ? id.equals( : == null;     }     @Override public int hashCode() {         int result = name != null ? name.hashCode() : 0;         result = 31 * result + (surname != null ? surname.hashCode() : 0);         result = 31 * result + (id != null ? id.hashCode() : 0);         return result;     }     @Override public String toString() {         return "Person{" +                 "name='" + name + ''' +                 ", surname='" + surname + ''' +                 ", id='" + id + ''' +                 '}';     } } Kotlin: data class Person(var name: String, var surname: String, var id: String) As you can see, Kotlin saves all of the Java boilerplate code that’s needed. 3. Improved Compiler Humans make mistakes and software has bugs. Some of the causes of these bugs can now be detected whilst coding and not only when running the app. Error messages are more precise, and the compiler is now better at pinpointing the exact piece of code that needs fixing. Further to that, code completion is faster and there is increased reliability in debugging. Lastly, building the app, whilst developing, is way quicker. One such improvement is the handling of nulls or, as it’s often referred to, The Billion Dollar Mistake. Be it Objective-C or Java, a pain point for developers is the null reference which causes runtime exceptions or apps crashing. To overcome this, Kotlin provides null safety at compile time with Swift utilising the Optional type. Code examples: Swift let number: Int? = 10 let letter: String? = "abc" Kotlin val number: Int? = 10 val letter: String? = "abc" 4. Open Source The inner workings of the language are freely available to explore, meaning that the developer community at large are constantly working on finding and fixing bugs - this is really why the language has been able to grow in stability. Today on the Swift repo there’s 104 000 commits,  27 000 merged pull requests, 8 400 forks and 341 branches. Kotlin also has astonishing stats: 65 000 commits, 1 372 merged pull requests, 3 900 forks, 3 900 branches. Both languages are actively maintained by both the original developers and the community. A side effect of this is that the languages are also available to perform other tasks. We now have Swift on the Server, Swift for Windows and many other projects and new operating systems. Whilst none of these are mature, being open source does drive the penetration of the language. 5. Industry Standard Over 50% of Android developers now use Kotlin, and Google themselves now take a Kotlin-first approach with many of their new features and libraries being offered first in Kotlin. Apple re-wrote foundational parts of their established operating system in Swift. As an example, on MacOS, the Dock (which is used to launch and switch between apps) is now in Swift. Uber’s iOS code base is now 90% Swift, and many other big apps have either already begun or completed their migration to it. Netflix, Evernote, Lyft, Twitter, Pinterest, Flipboard and AirBnB are just a few examples. Further to this there are also official communities from Podcasts to a Subreddit and even a Slack Group all aiding in taking the languages forward. 6. Future Support If anyone has learnt iOS development in recent years, they would have learnt Swift. And as time goes on, the only developers who can support Objective-C will be the senior developers who have been working on iOS for an extended period of time. The same roadmap will unfurl as developers migrate from Android to Kotlin. Whilst both Apple and Google have made their intentions clear on the way forward for development, it’s unlikely that either predecessor language will become completely obsolete. However, it will become very niche, and already some of the documentation on Objective-C development from Apple has been retired. 7. Developer Happiness This deserves a noteworthy mention. When both Lyft and Basecamp rewrote their Kotlin apps, one of the driving factors was to make a huge difference in programmer happiness. To quote one of the senior engineers at Basecamp: “Happier developers leads to great code and ultimately a better product.” In addition, they wanted to improve developer work quality and speed. In the latest Stack Overflow Developers Survey, Kotlin and Swift positioned themselves at number 4 & 9 of the most loved languages to work in respectively. At the opposite end Objective-C ranked as the second most dreaded. TL;DR: Swift and Kotlin really are better languages - they’re cleaner and less laboured than working on the legacy languages. Debugging is superior and learning advanced coding techniques is easier. Whilst all the hard work and optimisations our teams are doing may not always be visible, our clients can rest assured that we are busy building an even better product that can be enjoyed long into the future! P.S. Don’t worry - it’s not all maintenance work, and we do have some exciting feature updates planned for the next year as well so watch this space!

  • The Making Of Metrics

    A developer’s view of the journey as we prepare to launch our newest Fabrik application to the world. Data - we all have it and it's our job as developers to try to figure out where to put it. Furthermore, businesses and teams are all trying to extract valuable insights from this data, which is easier said than done.  At immedia, we are not exempt from this rule and have spent our fair share of time wrangling our data to try and highlight key insights for the clients of our Fabrik platform. Metrics, Fabrik's new analytics and data visualisation tool, was born from the desire to consolidate our previous efforts in surfacing our data into a single self-service portal that would not only present informative data, but surface it with expedition. As a developer who’s been instrumental in building Metrics with cost, scale and speed in mind, I’ve been taught many lessons along the way – and I’d like to invite you along for a glimpse into my journey so far. In the Beginning The wilderness awaits When evaluating the data in any system you will generally find an assortment of formats: structured, unstructured, text, tabular, binary, some API endpoint written by a person that left three years ago (and also didn’t care that you would be using it today) – a primordial soup, if you will. This wilderness that is set before you can seem daunting but, much like mowing your lawn after a year, the reward is well worth it when you smell the freshly-mowed grass or enjoy a languorously luxurious picnic between neatly arranged flower beds and carefully planted rows of trees. Metrics started with these questions: Where do we need to trim our lawn and neaten up the hedge? What flowers do we need to get; are roses the best choice for our climate and budget? Where will we place our short flower beds and our tall trees? And most importantly – who will be coming to the picnic? Or more simply, data is used to answer the 5 W's: who, what, why, when and where? For Metrics, whilst planning our garden, we came up with the following key questions that we wanted to answer in the initial release candidate: (who is)/(when are they)/(what are they using when)/(where are they when) listening to the live stream of the client? (who is)/(when are they)/(what are they using when)/(where are they when) using the client’s mobile application? when is the client’s application downloaded? As for the ‘why’ – while the subjectivity of that question and the requirement for verification of the various possible answers can halt a project before it even begins, sometimes, the answers quickly reveal themselves. For instance, what we’re currently observing with Metrics is that our clients’ live-streaming and engagement have seen an upward trend over the last few weeks, which would most likely be attributed to a population currently in lockdown during the COVID-19 pandemic. Find Your Source The source is within you – or, at least, somewhere Once our questions were established, it was time for us to identify from where our answers would come. As alluded to in the previous section: in any system, there will be multiple sources of data available and the selection of the source is a process. It may require some trial and error before you find a source that appropriately answers your question. We’ll skip over the boring stuff here and outline the sources that we eventually identified: Streaming Audio streams are served from HAProxy which provides us with configurable log output options. We used these to configure the logging to output what we need to answer our questions. We’ll get to how we parsed this information in a later section of this post. App Engagement How people use the services and engage with content is tracked via Matomo. Matomo provides a powerful API for retrieving the tracked data. What’s more, it provides our members with total privacy. Application Downloads App download numbers are retrieved via the Apple App Store Connect API and Google Cloud Storage API. Both provide us with files in CSV format. We’ll talk about how we used these in a later section. Laying the Groundwork Foundations are important Now that we knew what we were solving for, and from where we would be retrieving our answers, we needed to decide on which approach we would take for processing, storing and displaying the data. We vetted some options and finally decided to use Azure Databricks as our data processor with Scala as our data processing language. Azure Databricks provides us with an Apache Spark cluster that we can scale on demand to meet workloads. It’s also fast. Very. Very. Fast. For storage of our processed data, we identified Azure Cosmos DB and Azure Storage; Azure Cosmos DB for its ease of storage and retrieval of data (with a familiar SQL-like syntax) and Azure Storage for cost effective storage of files. The data in Matomo was already being stored in a MySQL database which we don’t need to query directly because Matomo's API already provides us with all the data we need. We would have a .NET Core API serving as the gateway between users and the stored data and an Angular application that would serve as the frontend. With the outline of our garden in place we felt confident that we would be able to tame the wilderness set before us and we were ready to get started planting and arranging our flower beds. THE PEOPLE BEHIND THE DATA A key part of building a tool that provides insights on how humans are using the tool, is being respectful of the humans themselves. Before we jump in to all the technical details, it is important to note that at immedia we hold the privacy and data rights of the people that use our platform in high regard. This means that we are always thinking about what needs to be done to ensure that data is properly anonymised before surfacing it to the people who use the platform. Metrics fully anonymises the data before it gets surfaced. Anything that can be used to identify a user is removed. For instance: when processing our streaming data we perform a one way hash of the IP address of the request before all of our data processing is performed. Furthermore, Matomo, our analytics engine, has user privacy baked into its design and also discards identifiable information as soon as it can. Streaming From logs to lines Our pipeline for importing streaming data works roughly as follows: Every hour a log file is rotated on HAProxy and uploaded to Azure Storage via the post-rotate hook. We read these log files into our Azure Databricks environment via a streaming query. The log files are processed, and relevant information is extracted and inserted into Delta Lake tables. Identifiable information, such as IP addresses are dropped before we write to Delta Lake storage. We have another pipeline that will run and create rollups of our data for use with frontend applications, which roughly works as follows: It calculates the peak number of listeners for all the newly created sessions per minute and saves the result to Delta Lake storage. It then creates rollups of all our specified periods and stores it in JSON format in Azure Storage – we’ll look at some examples of this soon. Lastly, we have a pipeline that will: calculate and store peak, total and unique listeners for different periods of time, and write the entries to Azure Cosmos DB. Exploring Streaming Results Summary Data Calculation of the summary data is merely done as an aggregate count or sum over the period of the rollup. For instance, 'Total Sessions' is calculated as a count and 'Total Days' is the sum of all streaming session lengths. Streaming Numbers Streaming numbers are calculated as an aggregate over the size of the granularity specified. In the graph above, 'Total Sessions' is the count of all listens per day, 'Total Unique Listeners' are the number of people who listened per day, and 'Peak Concurrent' is the maximum number of listeners for that particular day. These are stored in Cosmos DB which allows us to search and display arbitrary ranges. Streaming Numbers by Hour Streaming Numbers By Hour are calculated as an aggregate over the hour of day for sessions. This graph depicts the sum of all hours, the count of sessions streamed by listeners, the number of people who listened per hour, the count of sessions that were started, and the count of sessions completed per hour. Streaming Session Length Breakdown Session Length Breakdowns are calculated by using the Bucketizer class in Scala. We count the amount of sessions for every single duration ranging from 1 minute all the way to 18 hours. The frontend displays this as a pie chart, while the raw rollup data looks as follows: Summaries By Dimension Summaries By Dimension are calculated as a group by aggregate over session data. For instance, the 'Total Sessions' section lists the count of sessions grouped by each source, displayed from highest to lowest. App Engagement While statistics that describe how people use the Android and iOS apps is an exciting part of our data for our clients, it was much less exciting in terms of the data transformation work to be done. In essence, we query the Matomo API and display the data on the frontends. Luckily for us, Matomo did the heavy lifting in this regard and our biggest concern was displaying the data. App Downloads Our pipeline for application downloads works roughly as follows: An Azure Function App retrieves the CSV files from the Google and Apple APIs respectively. The function app does some slight preprocessing on the files and then stores them in Azure Storage. These CSV files are read into our Azure Databricks environment via a streaming query. Databricks does some processing on the data and writes the results to Cosmos DB. The result of this pipeline is that we can query App Downloads for any arbitrary period. The summary data is calculated by running an aggregate count query against our Cosmos DB container. The charts are rendered by querying Cosmos DB and displaying the entry of each day. The summary data is calculated by running an aggregate count query against our Cosmos DB container. The charts are rendered by querying Cosmos DB and displaying the entry of each day. Live Data Initially one of our goals was to surface data and surface it with speed. Up until this point we have only discussed static rolled-up data and the exploration thereof. Whilst this is useful for doing some rudimentary analysis after the fact, these stats are not able to tell our clients what is happening right now. In other words: we haven’t checked expedience off our list. To surface live data, we had to do some out of the box thinking. Processing log lines in real time wasn’t feasible as we only rotate the log every hour (unless of course you deem an hour ago as “live”) and we couldn’t really speed up the rotation. Live Stream Listeners For stream listeners there are two distinct types. HLS streams and Icecast streams and both of these required a unique approach to surface the live listener data. For HLS we wrote a .NET Core application that we deployed to our HAProxy server. This server checks the HAProxy Stick Table for the listener count of the tenant. We initially tried the HAProxy Stream Processing Offload Engine but this went bad – very bad – as it could not handle the amount of requests our servers were doing. In the end we got it working along the following lines: Our .NET Core application runs a command to check listener counts on the HAProxy Stick Table. It sends the listener count over Azure Event Hubs. An Azure Function picks up the event hub message and stores it in Redis (we keep about 2 hours of this data in Redis). We query Redis to show live stream data. Icecast was slightly simpler to retrieve the live listener count for, as it exposes administration endpoints that return XML data. The process is roughly as follows: An Azure Function imports the listener count from Icecast. We store the listener count in Redis. We query Redis to show the Icecast stream data. Live App Visitors & Engagement Retrieving the live app engagement numbers follows a very similar pattern to the Icecast listener count imports. We rely on Matomo’s reporting to achieve this. The process is roughly as follows: An Azure Function imports the current live visitor count and the actions taken in the last minute. These values are stored in Redis. We query Redis to show the App Visitor data. Events Prior to our Metrics application, Fabrik already had an Azure Event Hub to which it would report events. The reported events are retrieved via an Event Hub Listener. The process is roughly as follows: An Azure Function listens for events on the Event Hub. It stores the events in Redis. We query Redis to show the event data. The example above is during a relatively quiet hour – it can get crazy at time as seen in the screenshot below. The Road Ahead Growing our garden All things considered, the creation of Metrics has been quite a journey for us and we have learned a lot about what it takes to build a data pipeline that is cost effective and scalable. We aren’t planning on letting the weeds grow in our data garden over the next few months either - our clients have multiple new features to look forward to that are sure to teach us new lessons and provide greater insights into our data. Our mission to figure out what data we have and where we want to share it is a lot closer to being complete, but will never be completely so. We hope that we can keep delivering valuable insights to our clients and help you answer some of your operational questions going forward by delivering new insights to you. This journey is not yet over and we’re excited and ready to take on the future of Metrics.

  • Smile 90.4FM becomes a trusted source for information in the midst of a global pandemic

    As the scale and severity of the COVID-19 pandemic continues to escalate across the world, we are all being inundated with fake news and misinformation on social media and private groups, sending fear and panic rippling through communities who desperately need a reliable, credible source of news. Smile 90.4FM’s programming style of positivity and hope in the ‘Mother City’ and their positioning as the ‘amplifying the good news’ station means that the Cape Town-based radio station are uniquely positioned and already geared to provide comfort and clarity to their community during a daunting period. This offers them the opportunity to cut through the noise and quickly establish themselves as a trusted voice at a time when the need is crucial. A new status quo calls for new approaches Empowered by the Fabrik suite of software applications since 2016, the station had provided their closest listeners with a mobile app in which they could send and receive direct messages with the station, as well as listen to podcasts and the live broadcast – wherever they were. Since launch, the platform’s direct messaging functionality has helped the station become closer with their audience. With a broadcast message, all app members receive a push notification immediately alerting them about a new competition, survey or call-to-action – leading to rapid response and healthy engagement from Smile 90.4FM’s most loyal listeners. And by empowering listeners to send the station voice notes and text messages, the app gives every listener a fair shot at having their opinion heard without the burden of a big phone bill for SMSes or phone calls. During this particular phase of uncertainty, Smile stepped up to the opportunity of being of service to their audience. Through a dedicated messaging channel within their mobile app, they supplement news broadcasts with timely, relevant and factual COVID-19 updates that contain an added focus on the Western Cape province. “It was imperative that we provided a credible, relevant, succinct and immediate update to the pandemic,” says Naveen Singh, Programming Manager at Smile 90.4FM. “Our main role was to ensure that we engaged, informed, entertained, and emphathised with our audience across all platforms.” Powered by Fabrik’s secure, private platform, each registered member of the app is automatically added to this channel and flagged to be notified whenever a new announcement is received about the COVID-19 pandemic. Individual members are able to exit the channel of their own accord, or mute the channel if they prefer not to receive notifications. By setting the channel as ‘read-only,’ the station can post streams of news-related updates and links to useful resources, while keeping the noise of well-meaning community members forwarding other types of info that may not have been fact-checked prior to posting. To get the content out rapidly to the audiences across their various digital properties – the app, Facebook and Twitter – the News team make use of Fabrik’s Smashboard member engagement dashboard to easily disseminate breaking news or share pertinent announcements from live national addresses in real-time. A key iteration in Smile’s live on-air programming is the broadcast of President Cyril Ramaphosa’s nationwide addresses which are also streamed live via the Fabrik-enabled app an website streams, as well as interesting daily segments on Coronavirus-related issues that may affect their listeners. Those segments are made available immediately after broadcast as podcasts in the app and on the website. In addition, the station has incorporated daily on-air calls to action into every half-hourly news bulletin as well as daily promotions prompting listeners to subscribe to the new COVID-19 channel along with information about the COVID-19 hotline and hygiene practices. And to bring as much awareness as possible to how their audience can stay safe, the advertising billboards that appear when listeners first open the app are being dedicated to educating their community about protective measures related to the virus. Does being ‘of service’ improve engagement? To monitor how the consistent app-based COVID-19 updates are being received, the station has been tracking their audience’s response in real time via Fabrik’s Metrics dashboard – a reporting and analytics tool that empowers radio stations to view and monitor live engagement data. What Smile observed is that more of the station’s existing app members are opening the app more often, drawn in by the need to be kept informed by a trusted voice in their own community. Since the COVID-19 Updates channel was launched on the 12th of March, an average of 5 updates have been sent to members of the channel every day, keeping them informed on the effects of the pandemic on local communities and health authorities without becoming a source of spam. Over the course of the ensuing weeks, the team noticed interesting correlations between the ongoing updates and the frequency with which new and existing members have been engaging with the app. In March, the app was used almost 4 times more than in the same month a year ago by more than twice the number of members and, notably, the number of individuals who opened the app over 100 times – the station’s most loyal app-based audience - increased by 57%. The overall app audience continues to increase by hundreds of new members every week since the commencement of the amplified COVID-19 coverage – demonstrating a sustained appetite for quality, factual, real-time news notifications. What this could imply is that new app members are responding to an increase in on-air or social media calls-to-action or that the station’s existing app membership are sharing the app with their friends and family specifically to receive trusted, consistent COVID-19 updates. Come for the news, stay for the community In correlation with the increase in app engagement, stats show that the number of live stream plays increased over this period. It seems that, while reading up on the latest COVID-19 news, more people are digitally ‘tuning in’ to what’s being played on-air – a significant outtake. It’s undeniable that the global COVID-19 pandemic the world faces with has left many disheartened and searching for clarity in a confusing landscape of misinformation and fake news. Smile 90.4FM’s early investment in a multi-channel approach has empowered the station to rapidly surround their community with accurate, verified news and educational information about the pandemic, supported by the effective but simple-to-use messaging and audience engagement functionality within their Fabrik suite of services. What’s more, the station was able to track the impact of their ongoing COVID-19 updates in real time using Fabrik’s data visualising tools, which provided them a glimpse into the effectiveness of their initiatives as well as the impetus they needed to pull the community together through this challenging period.

  • Maintaining scalable Cloud Systems in times of Unanticipated Peaks

    How Microsoft Azure’s scalability and elasticity allowed Fabrik to respond quickly to a rapidly escalating increase in community engagement during COVID-19. When immedia initially set out to build our Fabrik platform – a suite of ‘born-in-the-cloud' audience engagement tools and workflows - our development team elected to adopt a cloud-first approach in its development, using Microsoft’s Azure platform. Some of the benefits we considered in selecting Azure include: cost savings through economies of scale and a tenant-based system with shared resources; the inherent scalability, redundancy and reliability of Microsoft Azure which enables our applications to be automatically adaptable to increases in resource demand; the ability to take advantage of the monitoring and analytics of Microsoft Azure so that we can diagnose issues quickly and report accurately. the ability to adopt an Agile approach when architecting and developing the platform so we can be responsive to our clients’ needs, as opposed to over-engineering a system based on superficial and assumptive requirements. As the Fabrik codebase became more established and our service offering continued to diversify, our technical teams were able to add more and more features to our mobile apps, APIs and web-based tools aimed at empowering our clients to better serve their members with ease. As a result, the number of individuals using the Fabrik suite of applications in our platform has increased dramatically over time, and so in turn have our infrastructure requirements, which include PaaS (Platform-as-a-Service) offerings such as ASP.NET APIs and Azure SQL Databases. With the onset of the COVID-19 pandemic in early 2020, our clients and their members heightened their communication with each other, leading to an increased reliance on their Fabrik applications. Our technical teams therefore anticipated a rapidly-escalating increase in traffic to our platform, more unpredictable network traffic into our system, and more strain on our APIs and databases. When this kind of demand occurs, the specific nature of the demand is difficult to predict and although we were confident that the Fabrik platform would perform based on Azure’s many elasticity and scalability services, in unprecedented and extraordinary times like this, our team made the call to be on high alert in case of any bottlenecks in our systems that might require manual intervention. The primary impact was to our backend database system which was developed on Azure SQL Databases using the Elastic Pools deployment model. The elastic pools served us well because of the dedicated amount of resources that were allocated for our databases, but when the demand drastically increased, the allocated resources needed to be expanded appropriately to cater for the demand. In addition, due to the number of people engaging simultaneously, our API gateway which is hosted on Azure App Services needed to be scaled out to more instances as well. The following statistics indicate the response times of some of our API calls during peak days: Using Application Insights, we were able to identify specific API calls in our system that were taking more time than expected to process. During the same period, the usage on our database was as follows: Each spike in database usage indicates occasions when our elastic pool was being maxed out. Our infrastructure team mitigated this by increasing the capacity of the pool to meet the usage demand on the platform. When our databases were strained, this impacted the response times of our APIs. App visitors would experience slowness when using some of the functionality in the apps. After analysing this usage pattern, we were able to identify areas we could improve to better cater for this kind of unpredictable usage. We identified specific API endpoints that needed to be optimised and certain areas of the system that needed reworking to take advantage of the serverless capabilities of Microsoft Azure. One of those services is the use of Cosmos DB for serving ‘chat’ related data, which will be beneficial in improving the overall load on our API. Cosmos DB allows us to separate reads and writes across multiple servers that are possibly distributed across multiple Azure region - as opposed to SQL Elastic Pools, where reads and writes happen on the same cluster. We are actively investing time in decoupling our APIs into a more microservice model, through the use of Azure Functions which, together with CosmosDB, will help in distributing the load on our APIs at a global scale. Scaling up the database tier took minutes to resolve the issues experienced by people using the apps. Throughout this entire scenario, we were able to take advantage of Microsoft Azure’s monitoring, alerting and log analytics capabilities which gave us access and visibility into the health of the system, highlighting areas that required attention and/or improvement at a glance. Looking ahead, there are always going to be improvements we can make to our platform and applications to better serve our customers’ requirements and the requirements of their members. The monitoring we have in place allows us to make more informed decisions that keep improving scalability, reliability and availability, and that are more anticipative of the areas we need to be scaling up and out in response to unpredictable and unforeseeable circumstances.

  • Run smarter campaigns with Smashboard

    Use Smashboard's updated campaign functionality to facilitate campaigns, search and filter entries, select winners and find content to play out on air! Your Smashboard engagement dashboard recently received a number of upgrades aimed at empowering you to facilitate campaigns and competitions more easily - all in one place! Here are a few new things you can do in Smashboard: Create an automated campaign response Once you've created your campaign using the Campaign Manager in Smashboard, you can now create a customised automated response that will be sent directly to all entrants via the Contact Us direct conversation within their app. In addition to using this feature to acknowledge the participant's successful entry into the campaign, your advertiser might like to book this Automated Response to send the participant more information about their offer, share their contact information, or prompt them to visit the advertiser's website. Pick a campaign winner You can now select your competition winner/s from a list of unique entries (the individuals who have successfully entered) or from a comprehensive list which may contain multiple entries per entrant. Once you've created the campaign, follow these steps: Find the 'Action' section of your campaign. Click the '...' symbol, which will give you a couple of options, then click 'Winners.' From there, configure your campaign to either 'allow multiple entries' from entrants or choose from a list of unique entries (one entry per entrant). Lastly, choose 'Pick Winner' and Smashboard will randomly select a winner for you! Exclude recent winners from your campaign Using the same process, you can also disqualify an entrant that has already won a competition within a specified timeframe by checking the box that says 'Disqualify previous winners' and then specifying the time period you'd like to exclude. Filter for competition entries Smashboard's new Campaign filter gives you the option to filter out all campaign entries or only show campaign entries. This is particularly useful when you're receiving many different kinds of engagement from your members to Smashboard, and you'd like to search for campaign entries which you can then select to play on air.

  • Say Hello to Community Centre

    Use Community Centre to view real-time engagement, administer your app membership & configure your messaging settings. From day-to-day operations such as membership application and member suspension to managing a conversation or channel within your Fabrik-powered app, Community Centre has been designed to be the new go-to tool for community management! Here are a few ways you can start to use our newest addition to the Fabrik suite of applications: Administer your app membership On your Community Centre dashboard, you now have the ability to view profile information about each registered member of your community, approve or reject their application, or assign trusted privileges to members. Configure your Messaging settings You’ll also be able to configure the settings of the Messaging functionality within your app by adding new conversations or channels, editing or removing existing ones, or managing particular members within each group. View engagement metrics in real time Via Community Centre, you will be able to access your Fabrik Metrics dashboard (which is currently in Preview) – a real-time, data-driven system that empowers your stakeholders with the ability to observe and understand your audience’s engagement, instantly visualise your data and immerse into audience’s behaviour in real time.

  • There's a quiet revolution happening in broadcasting

    Radio has been a medium that has essentially stayed the same for the last century. A trusted, resilient and human centred medium that has withstood waves of technology disruption and even built communities around audiences of common values. But there is no denying that radio is often seen as sleepy, stagnant and disrupted by the digital and social revolution. Who would have thought then, that the most interesting thing happening in modern radio would be coming out of Africa, and Durban at that? Gagasi FM, one of South Africa’s best loved and the number 1 regional commercial radio station is delighting listeners with their new digital engagement platform. The Gagasi FM App available on Google Play for Android and the Apple App Store for iOS has created a trusted socialised space for listeners to become truly a part of the real time life of the radio station. On the 22nd November 2019, Gagasi FM launched their Gagasi FM App. During the launch Gagasi FM’s Head of Brand, Phinda Magwaza took guests through the Gagasi FM App on screen to demonstrate exactly what it can do. The Gagasi FM App includes, amongst others, these useful features; Live-streaming via the app so you can listen to your favourite radio station, anytime, anywhere! Real-time podcasts available within seconds of broadcast. Private and secure messaging channels with the Gagasi FM team and other listeners. Listeners are also able to enter competitions via the app plus submit music for possible airplay on the station. The Gagasi FM App also enables listeners to vote for your favourite song for the Urban Top 30. It’s literally Gagasi FM at your fingertips. Over 23 000 listeners have already downloaded the new Gagasi FM app with over 70% registering and opting into the Gagasi FM community. But this is not just another radio app. This is an ecosystem driven by audience interaction and engagement. A powerful backend collating all messages, storing all broadcast audio, and making it even easier for the station to create and deliver on podcasts. “Creating a socialised audience with a real-time feedback loop into the studio and amongst the community has been an incredibly exciting innovation for our creative teams,” commented the station’s Managing Director, Mr. Vukile Zondi. Gagasi FM’s Head of Brand, Ms. Phinda Magwaza added, “We did a soft launch over the December/January holidays and couldn’t be more excited by these early results. The audience is now taking us in new directions already with over 1 000 of them opting into the conversational channel Uthando 101 connecting with each other about life, love and living exclusively on the platform.” Gagasi FM is already getting more direct engagement from their audience community than through global social platforms. “This feels like African digital,” mused Zondi. “Visit your nearest App Store and get engaged. We are charting new journeys in modern media and using local, home grown IP to do it.” Zondi is referring to Fabrik, the Microsoft Azure cloud based platform powering their private digital community. Built by Durban technology team immedia, the hot new OTT technology is offering broadcasters a new freedom to build and own their own digital audiences. The world had better keep an eye on Durban as the city that’s leading the way in broadcasting revolutions.

Made in africa

Fabrik is proudly African intellectual property. 

contact us

+27 31 566 8000

69 Richefond Circle


Durban, South Africa

© 2020 Fabrik is a product of the immedia ecosystem.