All Activity

This stream auto-updates     

  1. Today
  2. Earlier
  3. We are all clear that the Internet is the best showcase for companies. However, the rules of the game are the same for everyone, large and small companies. This, added to the fierce competition we find today, makes small businesses find it more difficult to make their brand visible with an SEM strategy. Today I want to talk to you about Microsoft Advertising, the platform where small businesses can create their phone number leads advertising campaigns . We will see what it is and what benefits it can bring to your business, and I will also show you how it works with a step by step so that you can make your first campaign easily and simply. We started! Microsoft Advertising What is Microsoft phone number leads Advertising and why should you implement it in your company? Microsoft Advertising, formerly known as Bing Ads, is an online advertising management platform whose objective is to appear in the search results of the Microsoft Search Network for companies that decide to create their campaigns there. It works with a CPC system, or cost per click . That is, you invest your money so that the phone number leads ads appear in the search engine every time a user performs a search, using any of the keywords for which you have previously bid. And you only pay when the user clicks on the ad. Thanks to the visibility that your company achieves with Microsoft Advertising, you have the possibility of increasing traffic to your website , in addition to converting those leads into customers. Compared to other SEM solutions, and considering that Microsoft Ads are focused on small businesses, this is a phone number leads great solution for all those businesses that want to do advertising campaigns on the Internet. The benefits of advertising at Microsoft Here are the 8 benefits that a Microsoft Advertising campaign can bring to your business: It is available on all types of devices : Microsoft Advertising allows you to connect with all types of customers since it reaches all devices, at any phone number leads time and place. It allows you to reach users from all over the world : in addition, thanks to Social Ads and the possibility of filtering by geographical areas, you can limit the scope of your ads wherever you want. In addition, the application allows you to collect demographic data that will help you better understand where your potential customers are. It is compatible with other advertising platforms , such as Google Ads. In fact, you can import the data from them to create your Microsoft Advertising campaign. There phone number leads is no cost to open and maintain your account : the main advantage of the CPC system is that you only pay when a user clicks on your ad. The online stores can display the image and price of products. You have the possibility to create your personal keyword lists , thanks to its keyword research tools. You can customize the language of the campaigns, depending phone number leads on the location where you launch your campaign. Also, the tool allows you to keep track of the websites that a user visits after clicking on your ad.
  4. Hi All, I'm posting v0.84 of the LPDS for your comments, questions, and suggestions. One note is that section 8 will end up living in an accompanying document. It's present at the end of the Standard just to serve as a location in which to manage the content. Please give that section some thought, as I'd like it to cover the frequently asked questions that one may have when attempting to mentally process the Standard. Within a week or two I hope to have a preliminary pass at the LDS to LDPS conversion utility available, so folks can see how a given LDS file would appear, translated into the LPDS format. Thank you for giving this your time, it's greatly appreciated! TVC Lens Product Description Standard 0.84.pdf
  5. Ah, and one more quick typo. On table A.13 " Process Status (“INF”) Packet ", the table lists the label STATUS as STATUSL . I don't see it on 3.11 (correctly STATUS), but I do see it on 3.12.
  6. Hi, We added support to REQ=INF reports on our machines a long while ago. And recently due to a talk with a lab I've taken a look at our implementation, and noticed that for some reason we were sending MODEL to the Host. Which seemed a little odd, it doesn't really make sense to me for it to be there, and it doesn't make sens to me anywhere without DEV and maybe VEN records. So I've checked the VCA DCS document and and section states "The INF request type will contain only request type, job, status, and (optionally) CRC and model ID records." . This is the same for v3.13 draft 30 PDF, which is the most recent VCA DCS document I have, section 7.3.5 on page 92 (by TOC) / 95 ("physical"), and for 3.06 (earliest I think I have) section 6.3.6 on page 44 (TOC) / 50 (Physical). Looking for "model ID" I see it mentioned just a few other times in the document, but always for MODEL (i.e. in a section grouped with what are or should be DEV and VEN). Even though in other places MODEL is just referred to as "model" or "machine model" (which is also how it's called in its definition). I'm pretty certain that the intent here was to specify MID (which we sent as well, despite that "only", since it was usable by Hosts we worked with), not MODEL. Which makes even more sense considering MID is explicitly stated to be optional on requests, similar to CRC. So: Is this indeed a typo/mistake in the DCS, and this should be MID? I should stop sending MODEL, and the DCS should be corrected for the next 3.13 version? Or am I understanding this correctly, MODEL should be here? In this case, can you please explain why? Also, how important is that "only"? This specific interaction started after seeing a communication sample to a Host from a fairly serious vendor where the sample didn't include MID, but did include both VEN and MODEL. Beyond probably being superfluous, is this "wrong"?
  7. Hi Robert, Extremely late response on my side as well, I missed your response at the time, sorry about that. 1. At the moment there are only three sections there (3.11, 3.12, 3.13), so the work of reordering (if it's agreed to do so) is just switching around 3.11 and 3.13. While it could be a lot of work in theory, in this case it seems to me to be very little work. That said, it's very little work, so of course I don't mind doing it myself. Except, I will need the original editable document to do so, not the currently published PDF. And I expect that the concern over compatibility between the editors (Word 365 that the PDF was made with, and my OpenOffice/LibreOffice) and wanting to verify correctness of everything, especially on a document with active change tracking, may cause Paul (or whoever would otherwise do this) a lot more work and concern than doing to quick select>cut>paste operations? 2b. If this was written as a recommendation of maximum length, so recommending terseness, I'd actually fully agree. It's acceptable for a Standard to recommend using short short values without enforcing them. It's even fine to require a maximum length with some specific exclusion criteria (value is made up of words and extending to finish the last word? there are multiple values which are very similar so a few more characters are needed to clarify the differentiation? Something else?). But this is presented as a requirement/specification of maximum length, combined with a complete waiving of that maximum length whenever it is wanted without any specific criteria. "There is no maximum length but it's recommended to limit to X characters" can make perfect sense. "There is a maximum length of X characters unless the length is longer" not so much.3 3. And same point, I agree that allowing for overrides is fine, but that requires specifying explicit cases for the overrides. If the override is completely free and unlimited, then the constraint is meaningless, and should be either waived or re-written as a recommendation. "You must/can't do X unless Y" is fine, except where Y is "you want to" instead of something a lot more specific.
  8. The reason to send to a conveyor DO data different from the default would be to have it match what is sent to a specific machine/device that the conveyor would need to consider. (e.g. If any and all devices on a line receive DO=L then also a generic device should receive DO=L and not DO=B) But in that case having a different device type for conveyor won't help in any way, the conveyor itself could be "at any part of the lab process". Knowing it's a conveyor rather than a generic device doesn't help knowing if it's a conveyor feeding a generator, engraver, polisher, etc... So a new device type won't change anything, you'd still need to tie it to a specific location (device it stands before). Which I guess the way to do will be to have different MID set for each conveyor, and configure the host to send different DO depending on MID? In this case, though, since the decision on the host is in practice entirely dependent on MID, then what is the benefit of having a "CVY" device type to check CVY+MID when you can just as well check for DNL+MID? The device type doesn't add or change anything since MID should probably be specific to a single device anyway. Or, to avoid doing the MID tailoring, since in this scenario the Host is already differentiating based on device type, it may be more practical to have the conveyor present itself as the relevant device. Conveyor before the generator/s can say it's GEN, the one before the polisher/s can say it's FSP (?), and so on. That should give the conveyor full knowledge on what the machines it feed should or shouldn't do. If the possibility of modifying the standard is considered, though, I think it would be a better idea not to add another DEV option, but instead of expand the set of DO___ labels. That would directly do the work of letting a generic device get the important data for all machines, as well as allow DO to be properly handled as a single job-status information instead of having the Host modify it per device. There currently exist such variations for some of the machines, like DOENG for engraver (i.e. If it's a two-lens job that shouldn't be engraved you can, and should, send for such cases "DO=B" and "DOENG=0;1" instead of changing to "DO=L" especially for the engraver), DOCOAT for coating, and a few more, but there are (as far as I know) no equivalents for other devices such as polisher or generator (DOGEN does something else). Expanding those seems like a good way to disentangle the general what-in-the-job-should-be-processed of DO (and let it be the same for all supporting devices without having to adjust it per device), with a very straight-forward and accessible way to indicate what individual devices should do.
  9. We are running into an issue where a customer uses a conveyor belt in the lab. As there isn't a device type specific for conveyor belts, they've been defining it as "DNL" for a generic download device. For generic download devices, we don't currently go through much job logic based on breakage situations, position in process, etc. It is by definition generic and could be at any part of the lab process. However, this means that the conveyor belt might receive "DO=B" when there is a breakage in the process and should instead be receiving "DO=L", for example. Is there a benefit to define a device type abbreviation in the DCS for conveyors? Do others have examples where a conveyor might be treated differently from a generic download device? I'd like to propose a device type abbreviation like "CVY" for a conveyor belt to be added to the standard.
  1. Load more activity