Can the conversation data be used to improve your sales coaching, optimize your sales process, onboard your new sales reps faster, and gain a deeper understanding of your customers. But how do you unlock this data?
A lot of providers of conversational AI (I used to work for one) have analytics components as part of their platform which help you analyse conversations, and identifying trends in conversations, eg what your customers ask for, what their most common problems are, etc.
Related
My startup has a lot of event data for users using the app or website. I'm an analyst that wants to build etls to turn this raw data into useful tables to do analytics on. Does anyone have any suggests or resources I could look at to understand what the industry standard is for this? Looking for a framework to help guide which tables to build.
Currently we are organizing the data at the session level. We have a session properties table which describes useful properties for every session thats happened on our platforms. This is then used to build a basic funnel to see where users are dropping off before conversion. Unfortunately our product is such that there are multiple paths to conversion so one funnel doesn't capture all of it.
Your question is, essentially, "How do I start building a data warehouse from scratch." By your asking the question at all, I think it's likely you'd need several more years of dedicated experience before you could sit down and knock that out all by it yourself.
It is therefore my professional opinion that you should instead think about the problem in a different way.
Your question implies future tasks of Analyzing User Behavior, when in point of fact analysts create value by Testing Hypotheses Against Business Outcomes. Generally, this will involve testing things that you hope will:
Improve Marketing ROI
By channel (PPC, SEO, Affiliates, etc.)
Improve Conversion to Email Signup
Email Marketing Effectiveness
Improve Conversion to Sale
Improve Customer Retention / LTV
Etc. etc.
That's a pretty short list. Pick the one with the highest likely return on analysis investment, and start there.
Now it's time to build out good A/B testing facilities. A/B testing generates revenue. Funnel analysis was the most common form of paralysis by analysis in the mid-1990's; it's nearly eradicated so don't let it spread now. Those A/B testing facilities should record detailed performance data. Start setting up tests and execute them. Maybe you've already got somebody working on this... that's awesome.
As you find yourself planning to test a new Acquisition/Conversion initiative:
- You should then build out supporting internal datasets that contain your KPIs and data that align with levers that marketing can pull... e.g., Facebook lookalike lists can contain what data? I can target ads based on what criteria? Our customers have what attributes? Which prospects converted to sale? Then you have the data you need to tell Marketing how to make more money.
As you find yourself planning to test a Revenue Improvement initiative:
- You should then build out internal datasets that contain your specific KPIs and any behavioral data necessary to support or reject the hypothesis being tested. This might include multiple customer-engagement tables (site visits, emails sent/opened/clicked, sales). Lots of the tests you'll do will look a whole lot alike, so these analysis tables will iteratively grow and improve.
Over time you'll find that you've unintentionally built a data warehouse from scratch, and that it does a pretty good job of functionally serving the business. Once your startup gets big enough, they'll hire somebody to completely normalize everything, and it'll then take two years for their data warehouse to eventually align with your numbers -- and only then will it subsume your homegrown warehouse.
Since we're already giving away the farm here: you're nearly always going to eventually need your own spin on following basic table concepts. This is off the top of my head, but notice how all the tables intuitively join to each other:
Campaigns (ids, organization, urls, dates)
Sessions (CampaignID, EmailID, UserID, entry URL, date, conversion indicators)
Pages (PageID, SessionID, UserID, date, URL, previousPageID, nextPageID, eventID)
Tests (TestID, description, link to assets on file, begin/end dates, hypothesis)
TestSessions (TestSessionID, campaignID, SessionID, TestID)
Users (UserID, email address, date, CampaignID, SessionID)
Sales (UserID, SessionID, date, ItemID, amount)
Items (ItemID, Date, description, unit price)
Email (EmailID, UserID, send date, opened date, clicked date)
Good luck!
Can someone explain me in detail the role of a business analyst in a datawarehouse application with example?
Like a domain in credit card merchant data warehouse.
Thanks
This a very broad and subjective question.
In a nutshell, it depends heavily on to analyst level of involvement to date.
The best case scenario is when the analyst has already answered the clients questions and your job is only turn a pile of ad-hoc SQL queries into a DWH model (star scheme, conformed dimensions etc.) with daily updates and OLAP layer to facilitate reporting.
The worst case scenario is when the analyst is a total layman in this field and hence can offer little to no help at all.
For in between scenarios – have a look on this schematic breakdown of DWH project phases
Understand customer requirements – an analyst can help bridge the gap between the customer and IT lingo and also help formulate useful KPIs\Measures
Understand available data - an analyst can help locate source tables, understand relationships, JOIN and WHERE conditions etc
Design solution – an analyst is a customer for this phase, i.e, a good DWH model should be understandable for data analysts in terms of entities, naming conventions etc.
Deliver (including QA) - an analyst with good understanding of the business metrics (is 1M$ monthly sales real or is it a bug) can have a huge impact on this critical phase
I apologize in advance for the overly-long post, but I wanted to provide as much information as possible.
I've been building web database apps for years, but I'm stuck on a redesign that I've been wanting to do forever and I cannot seem to figure out. I'm hoping for a nudge in the right direction.
The business is a self-storage rental business. Tenants typically sign a contract/rental agreement with no specific end date and usually (but not always) pay each month on roughly the same day as their start date. So if you move in on the 16th, your rent is due on the 16th of every month (ignore those last few days of the month that not all months have). Some folks pay 6 months in advance, etc.
Here are the tables that I know/think I need.
Tenants (basic contact info)
Storage Units (information about each unit, square footage, maybe base monthly rate unless I decide to stick those values in a separate table so that I can easily change the base rate for all units of the same type)
Tenants <-> Storage Units (One customer can rent multiple units, but each unit can only have 1 or 0 tenants so maybe this doesn't need it's own table.)
The part that I am stuck on is the best way to handle the billing - no invoices are generated - tenants just need to remember to pay. I want to build this as a web app on a hosted provider so I don't know if I should be thinking about handling this with a nightly db script or from the web app side or if I can design it in a way that nothing special needs to happen each night.
Here's a simple example of what I need.
Joe rents Unit #1 on 1/1/2011 and pays for 1 month of rent ($50/month).
How do I build this so that if Joe doesn't pay for month 2 on 2/1/2011 he appears as past due and owing $50 (late fees also kick in after being late for 5 days and you are flagged for being locked out of your unit if you don't pay for 10 days). The employees have some discretion on late fees & lock outs if it's a long-time customer and they were just a little late, etc.
I think the most similar real-world design might be a cable television provider, but I'm having trouble putting it all together without making it overly complicated.
I will likely be building this in .NET 4 with MS SQL 2005/2008, but I don't think this is a technology-specific question.
If the three tables you listed are "obvious", it's equally clear that you'll need some tables for accounts payable and receivable. If you don't already have something for the accounting side of the business you'll have to add it into your site.
I'd wonder about any business that didn't have some kind of accounting software in place. The best thing, in my opinion, would be to find a way to let your web app tap into that data source in a secure, read-only way.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
In my company we often value the software to be almost the same as concurrent software on the market. While this is one way I'm interested of other (maybe more academic) ways of value and put a price on software.
Any ideas or methods that have been succesful for you?
While I'm not always a fan of Joel, this crusty old article from 2004 answers your question very well. You charge based on how many units you think you will sell at that price, with the goal of maximizing profit.
I've done some contract work in the past, and I based my estimate on:
The cost of the man hours to produce the software, from start to finish
Potential money the client saves by using the software
Cost of any planned support for the software
Any other related costs such as installation fees, documentation, training, etc.
Then I compared that to the industry standard. In my case it was usually cheaper, and I still made money. Thus both the client and myself were happy.
Edit:
Mind you the above method is for a single client, with a custom software solution, and a simple unlimited-use license.
If you want to know academic methods for pricing a product, I have an MBA I would like to sell you.
Seriously, it depends on a lot of things. Are you selling a service, subscription, or a "box"? Where is your desired position in the market? What do your customers have to spend?
Listen to your customers and be prepared to change your pricing strategy. If you ever hear a customer say, "Wow, I was expecting to pay more!", it may be time to raise your prices significantly.
Magsto, my bet is that this question will be closed pretty quickly as being "not programming related."
However, I will tell you that your question is quite a bit more complex than can be answered here. There are lots of factors including time in market, market size, ROI you can offer, competitive advantages or disadvantages, the structure of payments (credit card, purchase order, cash), and even time of year. I only have experience here because I run my own company.
Do you really want to ask programmers this question? I think not...
I value my product as a fraction of it's value for the client. My venture sells web apps so it's slightly different, but if a web app would streamline 75K worth of overhead out of an office's budget, I charge 25K for it.
If it's a one time sale you have the option to examine the client and what value it will deliver to them. If it's a publicly sold product, the options are very different.
The basic formula is to sell it for around 30% of what it's worth to clients/end users. If you can deliver better quality than the next company, pricing in step with them is a big mistake because you can make more and take a better market share by promoting the features that justify the cost.
Customers often perceive cost as equal to quality. If you want to position your product as the highest quality option, you might consider pricing at 20% more than other competitors.
The price of a product is just as much about market strategy as maximizing profit.
You might want to read this:
Securing a .NET Application
It's a bit long, but I do get into some pricing at the end.
I am a IT enterprenuer and I my venture is into web and application development domain. When we deliver any product to our clients we ask them that
-how much time they are able to save with our application in place.
-Then we ask them to value their own time. Ex how much do they make in an Hour
-Then we do
time saved * value of time (as per the client)
these is the value that turns out for one day. We do the similar computations and demonstrate them how much they save in month and in a year
Thereafter depending on the client and the result for monthly and annual saving we give them the final price quote.
We think that these is the best way to give a software pricing as in these process we are pricing the software as per the money that software is helping our client to save
I have looked around on net and these book was suggested on almost all the forums though I have not personally been through these book but here is the download link
Dont just roll the dice
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
A while back I worked with a software company that sold a specialized software product. Ever so often they would release a patch for free and a new version that would require an upgrade fee. This is typically how the software industry works.
After some time the company decided on a new strategy, Subscription based software. This turns out to be a way for the software company to charge a small, incremental fee for each "transaction" that is performed on their software. Under this model the patches and upgrades were included in the per/transaction fee and there was a 'true up' in the number of transactions every so often in order to collect their fees.
To me this seems like a better way to develop and sell software. The software company gets continual income stream, the customer doesn't have to worry about upgrade costs and such, and if the customer gets really big then your income stream grows with their growth.
The problem (and reason for this question) is that I don't see anyone doing that anymore. Is it because this model doesn't work? Have I taken an overly simplistic view of developing and selling software without seeing some of the negative sides of this model?
[EDIT] I am interested in the developers opinion on whether writing Subscription based software is a good way to develop software.
So this question is directed towards the professional developers who have worked on commercial applications: Can anyone speak with experience on this model and why it does/doesn't work?
I used to work for a company which moved from product license to subscription based model. Here are some observations about that:
Offer both product license and subscription models
In product license: user buys 'n' number of seats for their use.
In subscription models, customer buys your software for 'x' months time and 'y' people.
It will help you a lot if your company also develops 'consultants' who will work with your customers to get the software implementation etc at client site (any required installation, training etc)
In fact if you see services like GMail enterprise, Fogbuz etc they give different pricing options:
where you want the app hosted: your servers or their servers
you will be charged $x per number of people using the software
I think a subscription model (time based) will definitely work in the current times and in fact the cloud model helps towards such freedom in revenue models: for example, you can choose to 'subscribe' to a cloud database rather than purchasing a database server.
Yes it does. See salesforce.com for an example.
Red Hat seems to think it works. Buy a year of support get all the upgrades/etc/etc. Except they let you keep the product when the year is up (so.. I guess customers like that too =).
It's not exactly the same but basecamp from 37Signals is very succesful with a monthly fee basis, and FogBugz also uses the same model. The approach you're talking about here seems similar to the MircoPayment idea that was seen as a revenue earner in the early days on the web. I'm not sure if anyone succesfully made money from that model, I'm sure a lot of VC was spent trying.
[Edit] I think this an exellent way for small ISVs to run their businesses. The combination of SAAS and subscription is a great way of getting revenue quickly. There are a number of advantages
1) Continuous revenue
2) Small or zero initial payment, brings customers in, beats that credit card price point issue (it's easier to charge $10/month than $100 one off)
3) Builds a solid relationship between ISV and vendor
4) Chance to upsell, assuming the offering is good
And the only way you're going to be a big software vendor is by being a small one first.
Due to the nature of software development a subscription based model is really the way to go, but how do make sure that you have continues updates that actually make software worth subscription fees.
If you're providing a service it's a lot easier to motivate subscription frees but if you're planning on having people pay monthly for monthly releases, well than that's a thin line between success and utter failure. I don't see how this would work with most software.
Update: #Dscoduc
I would call that a service then. Make a clear distinction between software release schedule and support. If you want to charge for a premium support deal well that service gonna have to be pristine. But I do see how it could work. People might end up buying subscription based software on the premises that they will be able to tailor it to fit their needs without programming experience and at a low cost.
Your challenge lies in being able to listen to your customers and really find a way of taking their feedback and making that the foundation for your software life-cycle and that's not going to be an easy thing to do.
Maybe we should petition stackoverflow for a way of marking content not related to programming but interesting to programmers.