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 1 year ago.
Improve this question
I would like to understand what price will generate my chatboot developed in Dialog Flow CX.
I have read the page https://cloud.google.com/dialogflow/pricing but it is not entirely clear to me.
With Dialogflow CX, you pay per session? by request?
And that is considered a request?
A request is generated every time that the end user writes a question in the chat bot?
Or a request is equal to a session?
According to the price page, $0.007 per request.
For example:
A user opens a conversation with the chatbot
And ask 5 questions, with its 5 responses from the chatbot
What price would it generate?
$0.007 by one session
or $0.007 by questions? $0.007 x 5 = $0,035
Thanks
As per the Pricing documentation, a request is defined as any call to the Dialogflow service. Note that a request is not equivalent to a session - a session may consist of multiple requests.
Moreover, also note that a new Dialogflow CX pricing model (2021-09) will take effect on September 1, 2021 - customers will be charged per request. Until that date, the original prices (2020-09) are in effect - customers are currently charged per session.
For your example, where the end-user asks 5 questions by sending text requests to a chatbot and receives 5 responses from the Dialogflow CX agent, this counts as 5 text requests, and the cost would be:
CX Agent (2020-09) (current): $20 per 100 chat sessions
If you have 5 requests that are sent by the same end-user, it is considered as 1 session only. Hence, the cost will be $0.20.
If you have 5 requests where each request is sent by different end-users, it is considered as 5 sessions. Hence, the cost will be $1.
CX Agent (2021-09) (starting September 1, 2021): $0.007 x 5 = $0.035
Basically, each time an end-user sends a query to the agent, the Dialogflow API’s detectIntent or StreamingDetectIntent method gets called and that counts as one text request or one audio request, depending on whether the application sends text or voice data to Dialogflow.
so for the most recent CX Agent (2021) you will pay $0.007 per request, so using your example if a user asks 5 questions thats 0.007*5 = $0.035.
If you're using a 2020 CX Agent you'd be paying $20 per 100 sessions, a session would be any conversation the agent would have with one user. So if your user asked 100 questions it would still be considered one session.
Related
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 8 days ago.
Improve this question
I cannot find any mention of what the actual monthly quota is.
https://learn.microsoft.com/en-us/bing/search-apis/bing-news-search/reference/error-codes
If you look inside the documentation for Bing Web Search API, you can read that:
The service and your subscription type determine the number of queries
per second (QPS) that you can make. Make sure your application
includes the logic necessary to stay within your quota. If the QPS
limit is met or exceeded, the request fails and returns an HTTP 429
status code. The response includes the Retry-After header, which
indicates how long you must wait before sending another request.
And if you head over to the Pricing section, you can find the TPS (transactions per second) limit and the limit per month.
I want to have the user respond with a longish response, like talk about their education and family background. In this, I would like to identify multiple intents and then go back to the user with multiple questions (one by one) as a follow-on to the intents detected. Can I do this in DialogFlow CX and how?
Note that your desired use case is currently not feasible in Dialogflow CX. By default, Dialogflow matches a user query to only one intent route. Intents are matched based on the confidence value in the detectIntent Response’s queryResult.match field.
Moreover, the maximum detect intent text input length is 256 characters. If you are using an integration, the integration platform may have a smaller limit. However, you can use the sys.long-utterance built-in event to handle user queries that exceed the 256-character limit. Note that the long user query will still only get matched to only one intent route.
If you want to ask the user multiple questions, you can design your agent to have a conversation flow that asks the user one question at a time. You can utilize State Handlers to control the conversation flow. You may refer to the Voice agent design documentation for best practices for designing your agent.
You could do several intents with no response that has several follow up intents with your questions, u are going to need to change the number of context to match the amount of intents that you are going to use.
I use Appointment.Save API to create a meeting. And check the status by type get appointment.Resources[0].ResponseType.
I want Exchange can tell me the "accept" response as soon as possible, but some times it takes almost 1 minute 30 seconds to get the "accept" response.
I want to know what is the longest time that the meeting room's status change from "no response" to "accept" When use EWS API to create a meeting
my source code sample is:
Appointment appointment = new Appointment(exchangeService);
appointment.Resources.Add(<meeting room mail address>);
appointment.Save(SendInvitationsMode.SendOnlyToAll);
I'm not sure how predictable this will be because it depends on several factors:
Size of the Exchange environment (CPUs, disks, etc.)
Or whether this is O365 and how busy it is
How many meetings are currently in the accept process among how many rooms.
Because the accept process involves a workflow within the Exchange services, unless one knows the internals of that process, I doubt you can come up with anything beyond a best guess.
We currently use our applications to download some pins information for analytics purposes
Currently we hit the API on hourly basis but we have some problems with rate limiting, so we need the following questions to be addresses:
The documentation states that the rate limit is 1000 calls per hour per user token per endpoint. By looking at the HTTP headers apparently the actual limit is 200. So, which is the correct one?
Are GET /v1/pins/1234 and GET /v1/pins/5678 considered to be a call to the same endpoint?
Are there any application level (so, despite of the used user token) rate-limit in place?
Are there any IP level rate limits?
Since we use concurrent requests, are there any limitation on the number of CONCURRENT request? (which means: make another call from the same IP and using the same token, even if the previous one hasn't ended yet)
Thanks in advance.
PS: I tried to contact them via support form, but it returns a 422. Which is awesome!
For apps that is still in development stage the limit is 200. You will get 1000 if your apps passed the review.
The documentation states that the rate limit is 1000 calls per hour
per user token per endpoint. By looking at the HTTP headers
apparently the actual limit is 200. So, which is the correct one?
Ans: Its 10 per token per app id per hour for app in development(tested), 1000 per token per hour for production app.
Are there any application level (so, despite of the used user token)
rate-limit in place?
Ans: No, rate limit will be 10(app in development) or 1000(approved app)/hour for each tokens you have
Are there any IP level rate limits?
Ans: No
Since we use concurrent requests, are there any limitation on the number of CONCURRENT request? (which means: make another call from the same IP and using the same token, even if the previous one hasn't ended yet)
Ans: No there is no such limit but they will probably check for bot activity and you may end up with banned account, so please do maintain some delay in between requests for same token IMO 12 seconds should be enough
I'm coding a new website that will need users to enter their mobile phone number, the problem I'm facing is that I need to make sure that the user is in fact the owner of (or in this case, has access to) the mobile number.
The solution I've come up with is, upon number submission I send them a SMS with a token and ask the user to enter the token on my website, much like Google Calendar does. However I'm on a short budget and I need to make sure user A doesn't submit 100,000 mobile numbers, if that happens I'll be out of business in no time, since each SMS sent costs me about 0.10 USD.
So far, I've come up with the following solutions:
use a CAPTCHA (keeps some users away and it is still vulnerable to manual registrations)
limit the number of tokens a given IP address request (dynamic IPs, proxies, etc)
limit the number of tokens sent for a given mobile number (a user can request tokens for all the available numbers and when the real user tries to request a legitimate token, his number will be already blocked)
None of these solutions are perfect, how do you suggest I approach this problem?
In a recent project, we were associating SMS numbers with a user account. Each account needed a CAPTCHA and email activation. The user could activate SMS via token, like you are using.
You could rate limit IP addresses (not a total limit). No more than 10 requests from an IP within 5 minutes, or something like that.
And/or you could limit outstanding SMS requests. After an IP address requests a token for SMS, it must be submitted before that IP can request for another SMS number. Or no more than 10 outstanding SMS tokens per IP per day.
Also, like #Alan said, we put a cap on our SMS messages per month.
I would use a combination of CATPCHA and Limit the requests of a Given Mobile Number.
In addition you should be able to specify with your SMS aggregator a preset limit per month. After you reach that limit, service is shutoff. That way if you are a victim of an attack, you will only be liable for a limited amount of money.
Instead of SMS, you can make use of an automated service that calls a phone number speaks out a One Time Password (via Text 2 speech). These services are similar in pricing to SMS, and less likely to get spam abused, as there is more overhead.
Twilio cost $0.03 a minute, or in this case, $0.03 a call.
You could do what Twitter does, which is have the user text you the token (rather than you texting it to them).
This will require you to find a provider that let's you receive texts for free (or close to it), but that might be easier.
Why is SMS costing you a dime? Utilize the EMAIL address that is associated with every SMS system (at least here in the U.S).
http://www.sms411.net/2006/07/how-to-send-email-to-phone.html
If someone tries their best to abuse a system, they will more than likely find a way to do it.
Using a combination of the techniques you've already come up with is likely the best way to thwart most malicious users.
Limit what people can do (no more than 10 requests from 1 ip in 10 minutes, one phone number can only recieve 3 texts a week, captcha before number entry), but more importantly, if people have no control over the content of the message there's no real reason to exploit it.